Kiểm tra CPU, RAM, swap và tiến trình khi Linux server chạy chậm
Dùng uptime, top, free, ps và vmstat để phân tích Linux server chạy chậm; đọc load average, RAM available, swap và OOM trong cùng thời điểm sự cố.
“Server chậm” là triệu chứng, chưa phải chẩn đoán. Người dùng có thể chờ DNS, ứng dụng chờ database, tiến trình chờ đĩa hoặc CPU thật sự bận. Nếu chỉ nhìn RAM gần đầy rồi reboot, bạn có thể làm mất bằng chứng mà vẫn không giải quyết nguyên nhân. Bài này trình bày cách thu thập số liệu cơ bản trên Ubuntu Server 24.04 LTS trước khi thay đổi hệ thống.
Chốt triệu chứng và khoảng thời gian
Ghi rõ thao tác nào chậm, chậm với mọi người hay một nhóm, bắt đầu lúc nào và có thay đổi gần đó không. Đối chiếu thời gian ứng dụng với giờ server. Một lệnh trả nhanh ở terminal không chứng minh website nhanh; một trang web chậm cũng không chứng minh kernel gặp vấn đề.
Thu thập khi có triệu chứng, không chỉ sau khi hệ thống đã trở lại bình thường. Với tình huống lặp theo giờ, xem cron, timer, backup, logrotate và tác vụ ứng dụng chạy cùng thời điểm. Không mặc định tương quan thời gian là quan hệ nhân quả; cần kiểm tra tài nguyên và hành vi của tác vụ nghi vấn.
Ví dụ trong bài là các phép đo thời điểm và cửa sổ ngắn. Chúng không tạo lịch sử dài hạn. Khi cần xu hướng, đưa máy vào hệ thống monitoring phù hợp, nhưng trước hết phải hiểu chỉ số đó đo gì để tránh cảnh báo sai.
Chụp trạng thái tổng quan bằng lệnh ít tác động
date -Is
uptime
nproc
free -h
vmstat 1 5
ps -eo pid,ppid,user,stat,%cpu,%mem,rss,comm --sort=-%cpu | head -15
Ghi lại phiên bản công cụ nếu đầu ra khác với hướng dẫn. Các lệnh này cũng tiêu thụ tài nguyên dù thường nhỏ; trên máy cực kỳ quá tải, tránh chạy vòng lặp thu thập dày hoặc xuất log không giới hạn. Không chia sẻ command line đầy đủ nếu tiến trình có thể chứa credential trong tham số.
uptime cho thời gian hoạt động và load average. nproc cho số đơn vị xử lý khả dụng theo bối cảnh lệnh, không phải mô tả đầy đủ mọi giới hạn CPU của VPS hoặc container. ps là ảnh chụp theo cách tính của công cụ, trong khi top và vmstat có cửa sổ lấy mẫu khác; không ghép các giá trị khác thời điểm như cùng một phép đo.
Đọc load average cùng với CPU và trạng thái tiến trình
Load average trên Linux liên quan số tác vụ có thể chạy và tác vụ ở trạng thái chờ không ngắt được, thường liên quan I/O. Vì vậy, load cao không đồng nghĩa CPU đang chạy 100%. Xem thêm CPU utilization và trạng thái tiến trình để phân biệt.
Trong top, chú ý thời gian user, system, idle, iowait và steal nếu có. Steal có thể phản ánh thời gian vCPU không được hypervisor cấp để chạy; nó cần được đối chiếu với số liệu nhà cung cấp. Iowait cũng không phải phép đo hoàn chỉnh độ trễ mọi thiết bị, nên tránh kết luận “ổ đĩa hỏng” chỉ từ một tỷ lệ cao.
Với vmstat 1 5, dòng đầu thường phản ánh trung bình từ khi boot theo một số trường, các dòng sau theo khoảng lấy mẫu. Xem hàng đợi runnable, blocked, swap in/out và CPU trong cùng cửa sổ. Một đợt tăng ngắn khi cập nhật package có ý nghĩa khác với tình trạng kéo dài làm người dùng không thao tác được.
ps hiển thị %CPU theo cách tính có thể là trung bình trên vòng đời tiến trình, không nhất thiết là mẫu một giây vừa xảy ra. Nếu tìm tiến trình nghi vấn từ ps, tiếp tục quan sát bằng top -p PID hoặc công cụ đo theo khoảng phù hợp. Đối chiếu với chức năng tiến trình thay vì kill vì nó đứng đầu bảng.
Mô hình kỹ thuật để giải thích cơ chế; không phải bằng chứng kiểm thử.
Phân biệt RAM dùng, cache và thiếu bộ nhớ
Linux dùng RAM cho cache để giảm truy cập lưu trữ. Bộ nhớ “free” thấp chưa đủ chứng minh thiếu RAM. Trong free -h, xem available cùng với swap, áp lực bộ nhớ và hành vi ứng dụng. Khái niệm MemAvailable được giải thích trong tài liệu /proc của Linux kernel.
RSS giúp thấy phần bộ nhớ resident của tiến trình, nhưng cộng RSS của mọi tiến trình có thể đếm lặp vùng dùng chung. Một tiến trình có virtual size lớn cũng không đồng nghĩa nó đang chiếm đúng từng đó RAM vật lý. Khi cần phân bổ chi tiết, dùng công cụ phù hợp và hiểu cách tính shared memory trước khi báo cáo.
Swap có dữ liệu không tự chứng minh máy đang swap thrashing. Xem si/so của vmstat trong lúc có triệu chứng và độ trễ ứng dụng. Thêm swap có thể giúp một số tình huống thiếu bộ nhớ nhưng không chữa memory leak; nó cũng có thể kéo dài giai đoạn chậm khi working set vượt RAM.
Không chạy drop_caches theo một mẹo tối ưu chung. Thao tác đó có thể làm giảm cache hữu ích và tăng I/O sau đó, đồng thời không xử lý tiến trình đang giữ bộ nhớ. Tương tự, không thêm hoặc tắt swap trên production trước khi đánh giá workload, dung lượng và cơ chế phục hồi.
Không có dòng khớp chưa chứng minh chưa từng có OOM; lịch sử log có thể thiếu hoặc sự kiện nằm ở boot khác. Một container hay service có giới hạn cgroup có thể bị OOM trong giới hạn đó dù host vẫn còn RAM. Đối chiếu policy của runtime và log service trước khi mua thêm tài nguyên host.
Khi một tiến trình bị kill, tìm nguyên nhân trong log và thông tin runtime. Exit code hoặc signal đơn lẻ không luôn chứng minh OOM. Một người quản trị, supervisor hay timeout cũng có thể dừng tiến trình. Giữ mức kết luận tương ứng với bằng chứng có được.
Sơ đồ chẩn đoán: kiểm tra theo từng lớp trước khi thay đổi cấu hình.
Kiểm tra lưu trữ và các nguyên nhân ngoài CPU/RAM
df -hT
df -i
sudo ss -s
systemctl --failed --no-pager
Đầy filesystem hoặc hết inode có thể khiến ứng dụng không ghi được file tạm, log hoặc dữ liệu. Đây là lỗi khả dụng lưu trữ chứ không phải chỉ số RAM. Bài đầy đĩa tiếp theo trình bày cách tìm nguyên nhân trước khi dọn.
Nếu CPU, RAM và đĩa chưa giải thích triệu chứng, xem thời gian DNS, kết nối tới dependency, hàng đợi ứng dụng, connection pool và lỗi backend. Một request có thể dành phần lớn thời gian chờ dịch vụ ngoài, trong khi server nhìn có vẻ rảnh. Thu thập theo luồng request và tránh công bố dữ liệu người dùng trong trace.
Từ quan sát tới một thay đổi có kiểm chứng
Chọn một giả thuyết cụ thể: tác vụ backup làm tăng I/O, service bị giới hạn RAM hay tiến trình ứng dụng tiêu thụ CPU liên tục. Ghi số liệu nền, thay một yếu tố trong lab và đo lại cùng loại thao tác. Không cùng lúc nâng RAM, đổi kernel parameter và restart toàn bộ service vì không thể biết thay đổi nào có tác dụng.
Nếu cần dừng một tiến trình trong sự cố, xác định owner, chức năng và tác động trước. Ưu tiên cơ chế shutdown của ứng dụng hoặc systemctl stop khi phù hợp. kill -9 không cho tiến trình tự dọn dẹp và có thể làm mất dữ liệu chưa ghi; chỉ cân nhắc khi hiểu hậu quả và các lựa chọn nhẹ hơn không đủ.
Khi server gần không đáp ứng, console hoặc hệ monitoring ngoài máy có thể là nguồn bằng chứng khả dụng hơn một phiên SSH mới. Không tiếp tục tạo nhiều phiên đăng nhập nặng trên máy đã thiếu tài nguyên. Chuyển cho IT hoặc nhà cung cấp nếu nghi vấn hypervisor, thiết bị lưu trữ hoặc mạng ngoài quyền quản trị của bạn.
Tiêu chí xác nhận đã phục hồi
Đo lại đúng thao tác người dùng từng gặp lỗi và cùng khung thời gian đủ đại diện. Xác nhận service không còn restart bất thường, log không lặp nguyên nhân cũ và tài nguyên không tiếp tục tăng không giới hạn. Một lần tải trang nhanh ngay sau reboot chưa chứng minh memory leak hoặc tác vụ định kỳ đã được xử lý.
Lưu thời điểm, số CPU, giới hạn RAM/cgroup, các phép đo, tiến trình liên quan và thay đổi đã làm. Các con số minh họa chỉ dùng giải thích; không đưa ra ngưỡng phần trăm áp dụng cho mọi workload. Ngưỡng vận hành nên dựa trên baseline, yêu cầu thời gian đáp ứng và mức dự phòng của chính dịch vụ.
