Đ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.
Theo dõi 10.000 fd: poll tốn ~248 micro giây mỗi lần gọi, epoll chỉ ~130 nano giây. Tôi định chốt 'epoll là O(1)'. Rồi tôi tăng số fd sẵn sàng và nó lộ ra là O(số fd sẵn sàng), không phải hằng số. Ưu thế thật của epoll đến từ một giả định về tải. Đo thật.