Tổng quan module — Tài nguyên & Đo lường

TL;DR: Hai module trước dựng bản đồ: dữ liệu nằm ở đâu, và nó đi đường nào. Module này đưa cho bạn bộ thước để đo trên chính bản đồ đó. Bạn sẽ đọc top và load average cho đúng nghĩa (chúng không đo thứ đa số nghĩ), phân biệt RSS với VSZ để trả lời một tiến trình thật sự tốn bao nhiêu RAM, dùng iostat phán xử đĩa có bão hoà thật không, hiểu cgroups dựng trần tài nguyên cho container thế nào, đọc được một lần OOM kill từ dmesg, rồi khép lại bằng bốn ca chẩn đoán máy chậm bằng bằng chứng thay vì phỏng đoán.

Vì sao module này tồn tại

Có một khoảng cách kỳ lạ trong nghề: gần như ai cũng gõ top mỗi tuần, nhưng rất ít người đọc định nghĩa của những con số trong đó. Hậu quả không phải là không biết gì, mà là tự tin mà biết sai — thứ đắt hơn nhiều.

Ba tình huống dưới đây đều có thật và đều lặp lại ở mọi đội:

• Load average 25 trên máy 8 lõi, cả nhóm quyết định thêm CPU. CPU đang rảnh 88%, nút thắt nằm ở ổ đĩa.
• Cảnh báo "RAM 190%" bật đỏ trên máy còn dư 6 GB, vì hệ thống giám sát cộng cột RSS của mọi tiến trình.
• Một container bị giết lúc 3 giờ sáng, log ứng dụng sạch sẽ, và biên bản ghi "chưa rõ nguyên nhân" trong khi kernel đã ghi lại đầy đủ mọi thứ.

Cả ba đều là cùng một lỗi: hành động theo một chỉ số mà không biết nó đang đo cái gì. Module này chữa đúng chỗ đó.

Sau module này bạn sẽ

• Measure tải hệ thống bằng top và htop, đọc load average đúng nghĩa trên Linux kể cả tiến trình D-state.
• Distinguish RSS, VSZ và PSS để trả lời một tiến trình thật sự chiếm bao nhiêu RAM.
• Diagnose thiết bị lưu trữ có thật sự bão hoà không bằng iostat, dựa trên await và độ sâu hàng đợi.
• Explain cgroups v2 áp trần CPU, RAM và I/O lên một nhóm tiến trình thế nào.
• Diagnose một lần OOM kill từ dmesg và phân biệt OOM cấp cgroup với OOM toàn máy.
• Explain trần file descriptor RLIMIT_NOFILE làm một service ngừng nhận kết nối mà vẫn sống thế nào.

Lộ trình module

Ba bài đầu đi theo ba tài nguyên cổ điển. Bài 01 mở bằng chỉ số quen nhất và bị hiểu sai nhiều nhất: load average đếm cả tiến trình đang kẹt chờ I/O, nên nó đo nhu cầu của cả hệ thống chứ không riêng CPU. Bài 02 chuyển sang bộ nhớ và giải thích vì sao tổng RSS của mọi tiến trình có thể lớn hơn RAM thật mà máy vẫn chạy êm. Bài 03 đóng nốt phần lưu trữ, và đây là bài có kết luận trái trực giác nhất module: %util 100% trên NVMe hoàn toàn không có nghĩa thiết bị bão hoà.

Hai bài giữa đổi tầng. Từ chỗ đo tài nguyên thật của máy, bạn bước sang tầng ràng buộc mà container dựng lên: bài 04 mổ cgroups v2 với hạn ngạch CPU tính theo chu kỳ và hai mức trần bộ nhớ, còn bài 05 kể chuyện xảy ra ngay sau khi trần bị vượt — kernel gửi SIGKILL, và bằng chứng duy nhất còn lại là một khối log trong dmesg.

Bài 06 là lab tổng hợp: bốn triệu chứng thật, mỗi ca một tập bằng chứng, và bạn phải phân xử nghẽn nằm ở đâu kèm dòng số chứng minh. Ba trong bốn ca có ít nhất một chỉ số chỉ sai hướng — đó là điểm chính của cả module.

Yêu cầu trước khi bắt đầu

• Đã học module 02 — Đường đi I/O & GPU, nhất là tuyến đường của một lệnh read(). Không có bản đồ đó thì các con số ở đây khó gắn vào đâu.
• Nắm trạng thái tiến trình và context switch — module này dùng lại các trạng thái R, S, D liên tục.
• Có một máy Linux để gõ theo thì tốt nhất; máy ảo hay WSL2 đều được. Không có cũng học được, vì mọi output đều in sẵn trong bài.
• Không cần quyền root, trừ vài lệnh đọc dmesg trên một số bản phân phối.

Thời lượng

Cách học module này hiệu quả

• Gõ song song trên một máy thật. Khác với hai module trước, gần như mọi lệnh ở đây chạy được ngay và không cần cài gì. Nhìn /proc/loadavg của chính máy mình đáng hơn nhiều so với đọc một con số in sẵn.
• Với mỗi chỉ số, hỏi hai câu. Nó đo cái gì, và định nghĩa đó có còn đúng trên phần cứng hôm nay không. Câu thứ hai là chỗ %util gãy, và là chỗ khiến bài 03 đáng đọc kỹ.
• Ba bài đầu là bộ ba đi liền. Load average nói có xếp hàng; vmstat nói xếp hàng vì CPU hay vì I/O; iostat nói thiết bị có thật sự đuối không. Học rời từng bài thì mỗi bài chỉ là một cái kính lúp.
• Đừng bỏ mini-challenge. Bài 06 mới là chỗ kiến thức biến thành kỹ năng, vì nó buộc bạn chọn công cụ chứ không chỉ dùng công cụ được chỉ định sẵn.

Bài tiếp theo: top, htop và load average — đọc cho đúng