top, htop và load average — đọc cho đúng

TL;DR: Load average trên Linux không phải phần trăm CPU. Ba con số ấy đếm số tiến trình đang chạy được (trạng thái R) cộng số tiến trình kẹt trong chờ không ngắt được (trạng thái D, phần lớn là chờ đĩa), lấy trung bình theo ba khung 1, 5 và 15 phút. Hệ quả thực dụng: load 8 trên máy 4 lõi có thể là bốn thread đang nằm chờ ổ cứng trong khi CPU rảnh gần hết. Muốn biết nghẽn CPU hay nghẽn I/O thì phải tách bằng cột r và b của vmstat, vì bản thân load average cố tình trộn hai thứ đó vào một số.

Bạn ssh vào một máy đang bị than là chậm, gõ uptime, và màn hình trả về:

load average: 25.72, 23.19, 23.35

Phản xạ đầu tiên của gần như tất cả mọi người là "CPU quá tải, thêm core đi". Phản xạ đó sai đủ thường xuyên để đáng viết hẳn một bài. Con số 25,72 kia có thể là dấu hiệu máy sắp gục, có thể là chuyện hoàn toàn bình thường, và trong không ít trường hợp nó chẳng liên quan gì tới CPU cả.

1. Analogy — phòng khám và ba loại người

Hình dung một phòng khám có bốn bác sĩ. Ở đó lúc nào cũng có ba loại người.

Loại thứ nhất đang ngồi trong phòng khám, tức là đang được phục vụ. Loại thứ hai ngồi ngoài hành lang, sẵn sàng vào ngay khi có bác sĩ trống. Loại thứ ba đã được đẩy sang phòng chụp X-quang và đang nằm chờ cái máy chạy xong; họ không tranh bác sĩ với ai, nhưng họ vẫn là bệnh nhân chưa xong việc.

Cách đếm của Unix truyền thống chỉ tính hai loại đầu, vì chỉ hai loại đó tranh nhau bác sĩ. Linux thì cố tình đếm cả loại thứ ba. Đó là toàn bộ chuyện gây hiểu nhầm.

2. Ba con số đó thật ra đếm cái gì?

Nguồn của chúng nằm ở một file văn bản, và đọc thẳng file đó cho nhiều thông tin hơn uptime:

cat /proc/loadavg
# 25.72 23.19 23.35 42/3411 43603

Năm trường, theo proc_loadavg(5):

• Ba số đầu là load trung bình trong 1, 5 và 15 phút.
• 42/3411 — 42 thực thể lập lịch đang chạy được, trên tổng 3411 thực thể đang tồn tại.
• 43603 là PID của tiến trình được tạo gần nhất.

Điểm mấu chốt nằm ở định nghĩa của ba số đầu: chúng đếm các tiến trình ở trạng thái R (đang chạy hoặc sẵn sàng chạy) hoặc D (uninterruptible sleep — ngủ không ngắt được, điển hình là đang chờ block I/O trả về). Một tiến trình ngủ bình thường chờ gói tin mạng hay chờ người dùng gõ phím thì ở trạng thái S và không được đếm.

Chuyện Linux đếm cả D không phải tai nạn. Nó đến từ một bản vá năm 1993 của Matthias Urlichs mà Brendan Gregg đã lần lại được, với lý do rất thực dụng: một máy có mười tiến trình kẹt chờ đĩa thì cảm giác nặng đúng như máy có mười tiến trình giành CPU, nên chỉ số "tải" nên phản ánh cả hai. Được cái này thì mất cái kia: từ đó, load average của Linux là nhu cầu của cả hệ thống, không còn là nhu cầu CPU nữa.

Chữ "average" cũng không phải trung bình cộng trong một cửa sổ. Kernel cập nhật ba con số bằng trung bình có trọng số giảm dần theo thời gian, nên một cú sốc đột ngột phải mất vài phút mới ngấm hết vào số 15 phút.

3. Đọc một con số load cho đúng

Bản thân 25,72 không nói được gì. Nó chỉ có nghĩa khi đặt cạnh số lõi:

nproc
# 32

Chia ra là 25,72 / 32 ≈ 0,8 — tức là trung bình mỗi lõi vẫn còn dư chỗ. Đúng con số đó trên máy 8 lõi thì thành 3,2: mỗi lõi đang có hơn ba việc chờ, hàng đợi dài ra và độ trễ đi lên. Vẫn chưa biết chờ cái gì, nhưng ít nhất đã biết là có xếp hàng.

Ba khung thời gian thì dùng để đọc chiều diễn biến, và đây là chỗ ba con số đắt hơn hẳn một con số:

Hàng thứ ba mới là hàng khó cho người trực, vì chẳng có đỉnh nhọn nào để nhìn thấy.

4. Vì sao load cao mà CPU vẫn rảnh?

Đây chính là tình huống bài mở đầu. Load 25,72 trên máy 8 lõi, nhưng top báo id (idle) tới 90%. Không có gì mâu thuẫn: phần lớn con số load đến từ những tiến trình D, và tiến trình D không tiêu chu kỳ CPU nào cả — nó nằm chờ thiết bị.

Cách tách nhanh nhất là vmstat, vì nó chia đúng hai loại ấy thành hai cột:

vmstat 1 5
# procs -----------memory---------- ...
#  r  b   swpd   free   buff  cache ...
#  1 24      0 812344  91232 5512488 ...

Cột r là số tiến trình đang chạy hoặc sẵn sàng chạy, cột b là số tiến trình bị chặn trong chờ không ngắt được. Đọc dòng trên: một tiến trình cần CPU, hai mươi tư tiến trình đang nằm chờ đĩa. Load 25 lúc này nghĩa là đĩa đang là nút thắt, và thêm CPU vào máy sẽ không cứu được gì. Muốn gọi tên đích danh thủ phạm thì lọc theo trạng thái: ps -eo state,pid,comm rồi giữ các dòng bắt đầu bằng D.

Còn khi đã mở top thì phần header mới là chỗ đáng đọc kỹ nhất, chứ không phải danh sách tiến trình bên dưới:

%Cpu(s):  2.3 us,  0.5 sy,  0.0 ni, 96.0 id,  0.8 wa,  0.0 hi,  0.3 si,  0.1 st

Tám trường này lấy từ /proc/stat, và ba trong số đó hay bị đọc sai:

• wa (iowait) — thời gian chờ I/O hoàn tất. Trực giác bảo wa cao là đĩa chậm, nhưng chính man page proc_stat(5) cảnh báo trường này không đáng tin: CPU không thật sự ngồi chờ I/O (lõi rảnh thì task khác được xếp vào ngay), còn trên máy nhiều lõi thì task đang chờ I/O không chạy trên lõi nào cả nên iowait của từng lõi rất khó tính cho đúng. Dùng nó làm gợi ý, đừng dùng làm bằng chứng.
• st (steal) — thời gian CPU ảo của bạn bị hypervisor lấy đi cho máy ảo khác. Trên cloud, st cao nghĩa là bạn đang bị hàng xóm chèn; không có dòng code nào của bạn sửa được chuyện đó, chỉ có đổi instance hoặc đổi chỗ.
• si (softirq) — công việc mềm của kernel, phần lớn là xử lý gói tin mạng; máy nghẽn mạng thường lộ ra ở đây trước tiên.

Cột %CPU của từng tiến trình thì có một chi tiết dễ gây hoảng: nó vượt 100% được. Một tiến trình 8 luồng chạy full trên 8 lõi hiện 800%, vì mặc định top tính theo một lõi chứ không theo cả máy. Muốn đổi cách tính thì bật chế độ chia cho số lõi bằng phím I, lúc đó cùng tiến trình ấy hiện 100%.

htop bày đúng dữ liệu đó nhưng dễ đọc hơn ở một điểm quan trọng: mỗi lõi một thanh riêng, nên tình trạng "một lõi cháy, bảy lõi rảnh" hiện ra ngay thay vì bị trung bình hoá mất.

5. Pitfall của riêng concept này

❌ Nhầm 1 — coi load average là phần trăm CPU.

✅ Nó là số việc đang dở dang, và trên Linux thì gồm cả việc đang kẹt chờ I/O. Muốn biết phần trăm CPU thì đọc %Cpu(s) trong header của top, hoặc mpstat -P ALL 1.

❌ Nhầm 2 — so load giữa hai máy khác số lõi.

✅ Load 16 trên máy 32 lõi nhàn hơn hẳn load 6 trên máy 2 lõi. Chưa chia cho nproc thì con số chưa có đơn vị.

❌ Nhầm 3 — thấy wa cao rồi kết luận đĩa là thủ phạm.

✅ wa là chỉ dấu, không phải bằng chứng, và nó nhiễu nặng trên máy nhiều lõi. Bằng chứng nằm ở iostat -x cùng số tiến trình D — đúng thứ bài 03 mổ.

❌ Nhầm 4 — thấy %CPU của một tiến trình là 400% rồi báo cáo là lỗi công cụ.

✅ Đó là tiến trình đa luồng đang dùng bốn lõi. Bật phím I trong top để đổi sang cách tính chia cho số lõi nếu bạn muốn con số nằm trong khoảng 0–100.

6. 📚 Đào sâu (tuỳ chọn)

Nếu chỉ đọc thêm một thứ trong danh sách trên thì nên là PSI: nó tách áp lực theo từng tài nguyên (CPU, bộ nhớ, I/O) và theo hai mức some với full, đúng chỗ load average cố tình mập mờ.

7. Liên hệ các bài khác

• RSS, VSZ và bộ nhớ thật — bài kế tiếp đọc nốt phần bộ nhớ trong cùng màn hình top mà bài này vừa mở ra.
• Đo I/O bằng iostat — khi load cao vì tiến trình D, đây là bước tiếp theo để chứng minh đĩa có bão hoà thật không.
• Trạng thái tiến trình và context switch — chỗ định nghĩa các trạng thái R, S, D; bài này chỉ dùng lại chúng.
• CPU-bound so với I/O-bound — lý do thêm thread không cứu được workload chờ đợi, nhìn từ phía bộ lập lịch.

8. Tóm tắt

• /proc/loadavg cho nhiều hơn uptime: ngoài ba số load còn có tỉ lệ thực thể chạy được trên tổng số đang tồn tại.
• Trạng thái D mới là chi tiết khiến load average của Linux khác Unix truyền thống, và là nguồn của gần như mọi hiểu nhầm quanh nó.
• Quy trình đọc gọn: chia load cho nproc để biết có xếp hàng không, rồi vmstat 1 tách cột r với cột b để biết xếp hàng vì CPU hay vì I/O.
• Trên cloud, nhìn st trước khi nghi ngờ code của mình; con số đó nói về hàng xóm chứ không nói về bạn.
• %CPU vượt 100% là bình thường với tiến trình đa luồng — phím I đổi cách tính.

9. Tự kiểm tra

Bài tiếp theo: RSS, VSZ — một tiến trình thật sự chiếm bao nhiêu RAM