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.
Đo một khoảng thời gian bằng đồng hồ treo tường rồi bị NTP giật lùi 10 giây giữa chừng: kết quả ra -10 giây, một khoảng ÂM không thể tồn tại. Monotonic thì cho +3 micro giây đúng đắn, không bao giờ nhảy. Chọn nhầm đồng hồ là bug timing kín đáo nhất. Đo thật.
clock_getres báo 1 nano giây, tôi tin hệ thống định thời tới nano giây. Nhưng nanosleep(1µs) ngủ thật ~84 micro giây — gấp 84 lần. Có một sàn ~80us do độ trễ đánh thức của bộ lập lịch, không phải độ mịn timer. Độ phân giải tự khai khác độ chính xác thật. Đo thật.
Giao một tín hiệu tới handler tốn ~500 ns. Nhưng cú đắt hơn là EINTR: một tín hiệu tới giữa nanosleep(10 giây) làm nó trả về sau 0,055 giây — và nếu bỏ giá trị trả về, bạn không hề biết. Đo thật.
Một tiến trình zombie có RSS ~0 KB, đo bộ nhớ thì tưởng vô hại. Nhưng nó giữ một slot PID, và PID là hữu hạn — đủ zombie thì cạn PID, fork() thất bại khắp máy dù RAM trống mênh mông. Tôi đã đo nhầm tài nguyên. Đo thật, kèm cái bẫy PID 1 trong container.
'Too many open files' (EMFILE, mỗi tiến trình) và '...in system' (ENFILE, toàn hệ thống) chỉ khác ba chữ, nhưng cần hai cách chữa khác hẳn. Tôi chạm cái thứ hai, phản xạ vá cái thứ nhất, gõ ulimit cả buổi không xong. Đo thật hai giới hạn fd và bài học đọc kỹ lỗi.