Process, CPU, RAM và tài nguyên hệ thống: lab top, ps, free, load và chẩn đoán nghẽn

Process, CPU, RAM và tài nguyên hệ thống là nhóm chỉ số anh phải nhìn ngay khi máy chủ chậm hoặc service phản hồi bất thường. Nhiều người chỉ mở top rồi nhìn thoáng qua, nhưng không hiểu load average, memory pressure hay process đang block I/O nói lên điều gì.

Bài này giúp anh đi từ cách đọc cơ bản đến một quy trình điều tra đơn giản nhưng dùng được ngoài thực tế.

1. Quy trình chẩn đoán khi server chậm

xem load và uptime
xem CPU process nào đang chiếm nhiều
xem RAM và swap
xem disk I/O nếu nghi nghẽn ghi/đọc
đọc log service liên quan

2. Các lệnh đầu tiên nên chạy

uptime
top -b -n 1 | head -20
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
free -h
vmstat 1 5

3. Hiểu load average

Load average không phải phần trăm CPU. Nó thể hiện số tiến trình đang chạy hoặc chờ tài nguyên. Nếu máy có 2 vCPU mà load duy trì 8.0 trong thời gian dài, gần như chắc chắn máy đang quá tải hoặc có nghẽn đáng kể.

4. Đọc RAM đúng cách

Trên Linux, RAM “used” không có nghĩa là xấu vì cache cũng dùng RAM. Hãy nhìn cả cột available trong free -h. Nếu available thấp, swap tăng và ứng dụng bắt đầu chậm hoặc bị OOM, đó mới là dấu hiệu đáng lo.

5. Tìm process bất thường

ps -eo pid,ppid,user,%cpu,%mem,cmd --sort=-%cpu | head -20
ps -eo pid,ppid,user,%cpu,%mem,cmd --sort=-%mem | head -20

Quan trọng không chỉ là process nào cao, mà còn là đó có phải hành vi bình thường không. Ví dụ backup nén file lớn dùng CPU cao lúc đêm có thể chấp nhận được, nhưng PHP-FPM tăng vọt giờ làm việc thì cần điều tra.

6. Lab tạo tải nhẹ để quan sát

yes > /dev/null &
ps aux --sort=-%cpu | head
kill %1

Lệnh trên tạo một process dùng CPU để anh nhìn thấy sự thay đổi trong top và ps. Chỉ nên làm trong lab.

7. Kiểm tra OOM và kernel warning

journalctl -k -p warning --since "1 hour ago" --no-pager
journalctl -k | grep -i oom | tail -20

Nếu kernel đã kill process do thiếu RAM, anh cần giải bài toán capacity hoặc memory leak chứ không chỉ restart ứng dụng.

8. Lab step-by-step

Chạy uptime, free -h, vmstat 1 5.
Mở top và quan sát cột CPU, memory.
Tạo một process tải CPU bằng yes như ví dụ.
Liệt kê top process theo CPU và RAM.
Kiểm tra kernel log để tìm cảnh báo.

9. Tài liệu chính thống

10. Checklist production

biết đọc load average theo số CPU của máy
biết phân biệt RAM used và available
biết tìm process top theo CPU và memory
biết kiểm tra OOM trong kernel log
không restart bừa khi chưa hiểu nghẽn nằm ở CPU, RAM hay I/O

11. Cách phân biệt nhanh CPU nghẽn, RAM thiếu và I/O chậm

Dấu hiệu	Nghi ngờ chính	Nên kiểm tra thêm
CPU cao liên tục, process đứng top rõ	CPU bottleneck	`top`, `ps`, số core, load average
RAM available thấp, swap tăng, có OOM	Memory pressure	`free -h`, kernel log, RSS process lớn
Load cao nhưng CPU không quá cao	I/O wait hoặc process blocked	`vmstat`, `iostat`, disk latency, log storage

Đây là chỗ nhiều người mới rất hay nhầm: load cao không đồng nghĩa CPU cao.

12. Hiểu load average theo số core

Nếu máy có 2 vCPU mà load trung bình đang là 0.5 thì rất nhẹ. Nếu load là 2.0 thì đang sát ngưỡng bận. Nếu load duy trì 6.0 hoặc 8.0, gần như chắc chắn có tắc nghẽn đáng kể. Khi đọc load, luôn phải đặt nó bên cạnh số CPU của máy:

nproc
uptime

13. Case thực tế: server chậm nhưng CPU không cao

Đây là case dễ làm người mới bối rối. Ví dụ trang web phản hồi rất chậm, nhưng top không thấy CPU nổi bật. Khi đó có thể:

disk đang chậm hoặc queue I/O cao
database query treo chờ lock
NFS hoặc storage mạng phản hồi chậm
process đang chờ network hoặc external API

Lúc này hãy mở rộng quan sát thay vì kết luận vội là “máy không sao”.

14. Lab mô phỏng 2 loại nghẽn khác nhau

CPU load lab:

yes > /dev/null &
ps aux --sort=-%cpu | head
top -b -n 1 | head -20
kill %1

Memory pressure lab nhẹ:

python3 - <<'PY'
a = 'x' * (200 * 1024 * 1024)
input('allocated 200MB, press Enter to exit')
PY

Sau đó chạy free -h và quan sát cột available. Chỉ làm trong lab, không chạy trên production.

15. Runbook chẩn đoán máy chậm trong 5 phút đầu

uptime để xem load và thời gian chạy.
free -h để xem RAM available và swap.
ps aux --sort=-%cpu | head và ps aux --sort=-%mem | head.
vmstat 1 5 để nhìn xu hướng ngắn.
Nếu nghi storage, dùng thêm iostat -xz 1 3 nếu hệ thống có sẵn.
Đọc log của service liên quan trước khi restart hay kill process.

16. Dấu hiệu cần đặc biệt cảnh giác

OOM killer xuất hiện trong kernel log
swap tăng dần suốt nhiều giờ
load rất cao nhưng CPU lại không tương xứng
một process tăng RAM mãi không giảm, nghi memory leak

Kết luận: hiểu đúng Process, CPU, RAM và tài nguyên hệ thống giúp anh khoanh vùng sự cố nhanh hơn và tránh xử lý kiểu mò mẫm.