Sao chép cả một tiến trình 256MB nghe phải mất hàng chục mili giây. Đo ra 133 micro giây, nhanh gấp trăm lần — vì fork nhân bảng trang chứ không chép byte. Rồi tôi suýt kết luận sai thủ phạm, cho tới khi tách 'đã cấp phát' khỏi 'đã chạm'. Và hóa ra fork là phần rẻ nhất; exec mới đắt. Đo thật trong container.
Ai cũng biết cấp phát stack nhanh hơn malloc, nhưng phép đo đầu của tôi cho hai bên bằng nhau — dấu hiệu đo sai. Sửa lại: stack ~1 ns cho MỌI kích cỡ, malloc chậm 6-14 lần. Đổi lại stack giới hạn 8MB, tràn thì crash không báo; heap trả NULL. Đo thật.
PMU là cửa sổ duy nhất thấy 'chậm vì trượt cache hay đoán nhánh sai'. Nhưng máy ảo không lộ PMU nên perf trả <not supported>. Tôi phải quay về đồng hồ — nó vẫn lộ hiệu ứng cache chậm 200 lần. Rồi demo 'mảng sắp xếp nhanh hơn' lại không tái hiện, vì một lý do bất ngờ. Đo thật.
Ai cũng tin 'load average = mức bận CPU'. Nhưng trên Linux nó đếm cả tiến trình kẹt chờ I/O — 4 tiến trình chờ đĩa đẩy load lên 4 dù CPU nhàn tênh. Cùng con số load 8, hai căn bệnh trái ngược. Và nó còn dâng chậm vì làm mượt. Đo thật hai lầm tưởng của chính tôi.
O_DIRECT bỏ qua page cache, nghe như tối ưu. Nhưng đọc lại từ cache buffered ấm nhanh gấp ~5 lần. O_DIRECT là I/O KHÔNG cache, không phải I/O nhanh. Và lần đo đầu trên bind-mount cho kết quả vô lý vì các tầng cache lồng nhau nuốt luôn cờ direct. Đo thật.
Chạm giới hạn fd cho lỗi EMFILE tự nâng được không cần root; nhưng nâng xong lại đụng một trần khác (ENFILE toàn hệ thống) không phải của mình. Đo thật trong container, và để errno nói thật đang chạm trần nào.