Hệ điều hành · 19/09/2026

Linux load cao và máy chủ chậm: Chẩn đoán CPU, I/O, RAM và process

Load average 20 không tự động có nghĩa CPU đang chạy 100%. Trên Linux, load còn tính các task đang chạy/chờ CPU và task ở trạng thái uninterruptible sleep, thường là chờ I/O. Vì vậy một server “load cao” có thể nghẽn CPU, disk, NFS, memory reclaim, hypervisor hoặc một kernel path khác.

Load average 20 không tự động có nghĩa CPU đang chạy 100%. Trên Linux, load còn tính các task đang chạy/chờ CPU và task ở trạng thái uninterruptible sleep, thường là chờ I/O. Vì vậy một server “load cao” có thể nghẽn CPU, disk, NFS, memory reclaim, hypervisor hoặc một kernel path khác.

Bài viết này trình bày quy trình từ tín hiệu tổng quan đến đúng process/cgroup gây nghẽn bằng uptime, top, vmstat, pidstat, iostat, sar và Pressure Stall Information (PSI).

Trước tiên: xác nhận người dùng đang thấy gì

“Chậm” cần được gắn với một triệu chứng đo được:

Latency API tăng hay request timeout?
SSH lag, shell đứng hay chỉ một service?
Throughput giảm dù CPU thấp?
Sự cố bắt đầu khi deploy, backup, cron hay traffic tăng?
Ảnh hưởng toàn host, một container hay một tenant?

Ghi timestamp và timezone. Đừng restart ngay; restart xóa process state, queue và bằng chứng quan trọng. Nếu hệ thống đang mất dữ liệu hoặc cascade, giảm tải trước rồi vẫn lưu snapshot tối thiểu.

1. Đọc load average đúng cách

uptime
cat /proc/loadavg
nproc
lscpu

Ba số load là trung bình khoảng 1, 5 và 15 phút. Chúng phản ánh số task ở trạng thái runnable (R) hoặc chờ I/O không ngắt được (D), không phải phần trăm CPU.

So sánh load với số logical CPU chỉ là bước định hướng. Load 8 trên máy 8 CPU có thể bình thường nếu workload CPU-bound và latency đạt SLA; load 4 vẫn có thể nghiêm trọng nếu mọi request chờ một disk chậm. Xu hướng quan trọng hơn một ngưỡng cứng:

1 phút cao hơn 5/15 phút: áp lực mới tăng.
1 phút thấp hơn 5/15 phút: hệ thống đang hồi phục.
Cả ba cao: áp lực kéo dài.

2. Snapshot tổng quan bằng top

top
top -H -p PID

Các trường CPU thường gặp:

us: user-space code.
sy: kernel/system time.
id: idle.
wa: CPU idle trong lúc hệ thống còn I/O outstanding; là tín hiệu, không phải “disk sử dụng bao nhiêu %”.
hi/si: hardware/software interrupt.
st: steal time, vCPU chờ hypervisor cấp CPU.

Nhấn 1 để xem từng CPU, P để sort CPU và M để sort memory. Một process 400% CPU trên máy nhiều core có nghĩa nó dùng khoảng bốn logical CPU; không phải lỗi hiển thị.

top dễ dùng nhưng snapshot có thể bỏ lỡ burst ngắn. Tiếp tục bằng công cụ sampling có interval.

3. vmstat: phân biệt runnable, blocked, swap và CPU

vmstat 1 10
vmstat -y 1 10

Dùng -y để bỏ dòng đầu tiên vốn là trung bình từ lúc boot. Tập trung:

r: task runnable/chờ CPU. Liên tục cao hơn số CPU gợi ý CPU queue.
b: task bị block chờ I/O.
si/so: swap in/out. Hoạt động liên tục cùng latency thường là memory pressure.
us/sy/id/wa/st: phân bố CPU.
cs: context switch; tăng cao cần đặt cạnh throughput và scheduler activity.

Pattern thường gặp:

r cao, id gần 0, wa thấp: CPU saturation.
b và wa cao: I/O path có vấn đề.
si/so liên tục: RAM pressure hoặc working set vượt memory.
st cao: tranh chấp CPU ở hypervisor/cloud host.

4. Tìm process bằng pidstat

Cài package sysstat nếu chưa có. Lấy nhiều góc nhìn theo interval:

pidstat -u -r -d -w -p ALL 1 10
pidstat -t -u -p PID 1 10

-u: CPU user/system và CPU number.
-r: page fault và memory.
-d: read/write I/O theo process.
-w: voluntary/non-voluntary context switch.
-t: hiển thị thread.

Thread view quan trọng với JVM, database, web server và runtime có thread pool. Một thread nóng có thể bị che trong tổng process. Ghi command line đầy đủ:

ps -eo pid,ppid,stat,psr,ni,%cpu,%mem,wchan:24,comm,args \
  --sort=-%cpu | head -30

5. Process state và uninterruptible sleep

Trong ps, các state chính gồm R runnable, S interruptible sleep, D uninterruptible sleep, Z zombie và T stopped. Nhiều task D thường làm load cao dù CPU rảnh.

ps -eo state,pid,ppid,wchan:32,comm,args | awk '$1 ~ /^D/'
cat /proc/PID/stack
cat /proc/PID/wchan

wchan/kernel stack có thể chỉ ra chờ block I/O, NFS, filesystem, lock hoặc driver. Task D thường không thể kill ngay; signal chỉ được xử lý khi kernel operation trở lại. Reboot có thể là biện pháp cuối, nhưng trước đó cần xác định storage/network/kernel path để lỗi không lặp lại.

6. iostat: disk nào đang nghẽn?

iostat -xz 1 10

Các trường thay đổi theo phiên bản, nhưng thường chú ý:

r/s, w/s: IOPS.
rkB/s, wkB/s: throughput.
await: latency trung bình gồm queue + service.
aqu-sz: độ dài queue trung bình.
%util: thời gian device bận xử lý I/O.

Không dùng một ngưỡng %util=100 cho mọi storage. NVMe, RAID, SAN và virtual block device có concurrency khác disk đơn. Đánh giá latency theo SLA và baseline của chính workload, kết hợp queue, throughput và application latency.

Tìm process tạo I/O bằng pidstat -d hoặc iotop -oPa. Kiểm tra kernel/storage log:

dmesg -T | grep -Ei 'error|timeout|reset|nvme|blk|ext4|xfs'
journalctl -k --since '-30 min'

7. Phân biệt memory usage và memory pressure

free -h
vmstat 1
cat /proc/meminfo
cat /proc/pressure/memory

Linux dùng RAM trống cho page cache; free thấp không tự động là thiếu RAM. Xem available, swap activity, reclaim và PSI. Khi memory pressure cao, task bị stall để reclaim/compaction hoặc swap, khiến latency tăng trước cả OOM.

Tìm process/cgroup:

ps -eo pid,ppid,%mem,rss,vsz,comm,args --sort=-rss | head -30
systemd-cgtop
cat /sys/fs/cgroup/system.slice/SERVICE.service/memory.events

Bài toán memory leak/OOM cần phân tích riêng; đừng drop cache như giải pháp định kỳ. Nó có thể làm I/O tăng và chỉ che triệu chứng.

8. PSI: đo thời gian workload thực sự bị stall

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

PSI báo tỷ lệ thời gian task bị trì hoãn vì thiếu CPU, memory hoặc I/O trong các cửa sổ 10, 60 và 300 giây:

some: ít nhất một task bị stall.
full: mọi task non-idle đồng thời bị stall; memory/I/O full kéo dài thường nghiêm trọng.

Load cho biết bao nhiêu task đang runnable/blocked; PSI cho biết workload mất bao nhiêu thời gian vì contention. Kết hợp hai tín hiệu tốt hơn chỉ alert load average.

Với cgroup v2, có thể đọc cpu.pressure, memory.pressure và io.pressure theo service/container để tránh một workload bị che trong metric toàn host.

9. CPU saturation: user, system, interrupt hay steal?

Nếu us cao, xác định function/code bằng profiler phù hợp; đừng chỉ kill process. Với native workload có thể bắt đầu:

perf top
perf stat -p PID sleep 10

sy cao có thể liên quan syscall, network packet, filesystem, lock hoặc kernel work. si cao thường cần xem packet rate và NIC distribution:

mpstat -P ALL 1 10
mpstat -I ALL 1 10
cat /proc/interrupts

st cao trên VM nghĩa hypervisor không cấp đủ CPU. Tối ưu code trong guest không giải quyết noisy neighbor; cần đổi instance/host hoặc làm việc với nhà cung cấp.

10. Scheduler, run queue và context switch

CPU 100% chưa chắc xấu nếu throughput tốt và latency đạt mục tiêu. Vấn đề là runnable queue và thời gian chờ CPU tăng. Dùng:

mpstat -P ALL 1
pidstat -w -p ALL 1
sar -q 1 10

Nhiều thread hơn CPU không tự động sai, nhưng thread explosion, lock contention hoặc spin loop có thể tạo context switch cao và throughput thấp. So sánh với deploy/config gần nhất: worker count, thread pool, connection pool, garbage collector và CPU quota.

11. Container và cgroup: host rảnh nhưng app vẫn chậm

Container có thể bị CPU throttling hoặc memory limit dù host còn tài nguyên:

docker stats --no-stream
systemd-cgtop
cat /sys/fs/cgroup/CGROUP/cpu.stat
cat /sys/fs/cgroup/CGROUP/memory.current
cat /sys/fs/cgroup/CGROUP/memory.events

Trong cpu.stat, nr_throttled và throttled_usec tăng cho thấy workload chạm CPU quota. Với Kubernetes, so sánh request/limit, pod throttling và node pressure. Đừng tăng limit trước khi hiểu traffic và regression.

12. Lịch sử quan trọng hơn snapshot

Khi sự cố đã qua, top hiện tại không trả lời quá khứ. Bật sysstat hoặc monitoring agent từ trước:

sar -u -f /var/log/sysstat/sa19
sar -q -f /var/log/sysstat/sa19
sar -r -f /var/log/sysstat/sa19
sar -d -p -f /var/log/sysstat/sa19

Đối chiếu với deploy, cron, backup, traffic, database checkpoint và cloud event. Baseline theo cùng giờ/ngày giúp phân biệt spike bình thường và regression.

13. Giảm tải an toàn khi đang sự cố

Tùy nguyên nhân, ưu tiên biện pháp có thể rollback:

Rate-limit/load shed request không quan trọng.
Tạm dừng batch, backup, index build hoặc worker priority thấp.
Scale out/vertical nếu đã xác nhận saturation và ứng dụng hỗ trợ.
Giảm concurrency khi dependency đang nghẽn; tăng worker có thể làm tệ hơn.
Rollback deploy/config vừa gây regression.
Dùng renice/ionice thận trọng cho batch, không thay thế sửa nguyên nhân.

Không kill database, flush cache, drop cache hoặc reboot chỉ vì load cao. Chụp metrics, process list, stack/log và I/O state trước; đánh giá tác động dữ liệu và failover.

14. Các kết luận sai thường gặp

“Load cao = CPU cao” — task D-state cũng tăng load.
“Free RAM thấp = thiếu RAM” — page cache là sử dụng hữu ích.
“iowait cao = disk chắc chắn hỏng” — cần iostat, process và storage path.
“%util 100 = mọi disk đã hết capacity” — thiết bị concurrent cần đọc khác.
“Một process 300% là bug” — có thể dùng ba core hợp lệ.
“Tăng worker sẽ tăng throughput” — có thể tăng queue và contention.
“Restart xong là đã sửa” — chỉ xóa triệu chứng và bằng chứng.

Playbook 15 phút

Ghi latency/error/throughput và timestamp.
uptime, nproc: load trend và số CPU.
vmstat -y 1 10: runnable, blocked, swap, wa, st.
cat /proc/pressure/*: resource nào làm task stall.
pidstat -u -r -d -w -p ALL 1 10: process nào gây áp lực.
iostat -xz 1 10: device latency/queue/throughput.
ps tìm D-state, thread nóng và command line.
Kiểm tra cgroup/container quota và throttling.
Đối chiếu log/deploy/cron/traffic.
Giảm tải có rollback, rồi xác minh SLA và viết postmortem.

Kết luận

Load average là điểm bắt đầu, không phải chẩn đoán. Muốn hiểu Linux chậm, cần phân biệt task chờ CPU với task chờ I/O, đọc xu hướng theo interval, tìm process/thread/cgroup và đo thời gian stall bằng PSI. Khi kết hợp vmstat, pidstat, iostat và dữ liệu lịch sử, bạn có thể chuyển từ “server load cao” sang một nguyên nhân cụ thể, biện pháp giảm tải an toàn và thay đổi phòng ngừa có thể kiểm chứng.