Mỗi lượt một tiến trình chạy ~3 ms rồi bị đẩy ra, và con số đó cố định dù 2 hay 8 tiến trình tranh CPU. Nhưng lần đầu tôi không thấy chia lượt gì cả (quên ghim CPU), và thứ tôi đang đo hóa ra là EEVDF chứ không phải CFS như tên bài. Đo thật hai cú vấp về bộ lập lịch.
Hai tiến trình tranh một CPU chia phần theo nice: 0 vs 5 ra 75/25, 0 vs 19 ra 98,5/1,5. Tôi suýt chốt 'nice 10 = chậm'. Rồi đo lại: nice 10 vs 15 chia y hệt 0 vs 5, vì phần chia chỉ phụ thuộc HIỆU nice, không phải giá trị tuyệt đối. Ưu tiên là chuyện tương đối. Đo thật.
Ghim CPU vào một nhân nghe hợp lý: cache ấm, không bị dời, chạy nhanh hơn. Nhưng đo ra ghim không hơn tự do — máy rảnh, dưới tải, kể cả khi ép dời liên tục. Vì bộ lập lịch đã tự giữ cache ấm, và phần cứng chia sẻ cache khiến dời rẻ. Tôi đã đo cho một lợi ích đã có sẵn. Đo thật.
docker run --cpus=1 cho container đúng một CPU. Chạy 1 luồng thì mượt. Nhưng 4 luồng đốt chung quota nhanh gấp 4 rồi CẢ BỐN bị đóng băng 85 ms mỗi chu kỳ — dù CPU trung bình không vượt hạn. Đây là CFS throttling, nguồn đuôi trễ số một trong container. Đo thật.
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.