Tôi dựng từng trạng thái R/S/D/Z/T rồi đọc /proc: một dd ghi đồng bộ nằm trong D (ngủ không-ngắt-được, kill -9 cũng phải chờ) tới 72% thời gian. Rồi liếc load average tưởng nó vọt lên, nhưng nó đứng im — vì là trung bình trượt 1/5/15 phút, phản ứng chậm. Đo thật.
Đọc lạnh từ đĩa 93ms, đọc ấm từ cache 18ms — nhanh gấp 5 lần. Nhưng lần đầu tôi đo, hai lần bằng nhau: hóa ra ghi file bằng dd đã nạp sẵn nó vào page cache, nên 'lần đầu' của tôi vốn đã ấm. Muốn đo đọc lạnh phải drop_caches. Đo thật, và cột Cached là đèn báo.
write() không fsync đạt ~984.000 ghi/giây, tôi suýt reo 'ghi đĩa nhanh khủng khiếp'. Nhưng đó là tốc độ page cache, dữ liệu chưa bền. Thêm fsync ép xuống đĩa: sụp còn ~2.578 ghi/giây (388us mỗi lần). Gộp một fsync cho cả lô cứu lại tốc độ mà vẫn bền. Đo thật.
malloc 512 GB trên một máy 7,75 GB RAM vẫn trả về thành công tức thì, vì overcommit chỉ HỨA chứ chưa giao RAM. Tôi suýt tin 'cấp phát xong là có RAM'. Sự thật lộ khi chạm trang: OOM killer giết đúng ở giới hạn thật, mã thoát 137, còn xa lượng đã cấp phát. Đo thật.
Khi hết RAM, nhân giết ai? Không phải kẻ vừa xin làm tràn, mà KẺ TO NHẤT — một tiến trình ngoài cuộc đang ngồi yên. Đo thật bằng oom_score và dmesg.
Thấy container dùng 255 trên 256 MB, tôi hoảng 'sắp OOM'. Nhưng nếu chỗ đầy đó là page cache thì container khỏe re, oom_kill=0; nếu là anon thì exit 137, bị giết ngay. Con số 'đang dùng bao nhiêu' đứng một mình gần như vô dụng — chỉ thành phần mới nói. Đo thật.