Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
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.
Đoán sai một nhánh chỉ chậm đi một chút? Đo ra: quét tỉ lệ nhánh được lấy từ 0% đến 100%, thời gian vẽ thành một hình chuông đỉnh ở 50% — nhánh đoán được (0% hoặc 100%) tốn 0,24–0,45 ns còn nhánh 50/50 tốn 2,38 ns. Từ đó suy ra phạt mỗi lần đoán sai ~3,86 ns, tức khoảng 12 chu kỳ CPU — đúng cỡ một lần xả pipeline.
Trên hai cột trùng nhau, planner đoán 99 hàng còn thực tế 10000 — lệch 100 lần. 'rows' của EXPLAIN là ước lượng (không chạy), 'actual rows' của EXPLAIN ANALYZE mới là đo thật (có chạy). Chính khoảng cách giữa hai con số tố cáo planner đang đoán mù — và EXPLAIN ANALYZE chạy thật cả UPDATE/DELETE.
Ép malloc về một arena chỉ làm 8 luồng chậm từ 556 xuống 434 triệu op/s — tưởng arena vô dụng. Nhưng có một biến ẩn đang gánh thay nó: tắt luôn tcache thì thông lượng sập còn 23. Hai lớp chống tranh khóa, mỗi lớp che hiệu ứng của lớp kia. Đo thật.
Bốn luồng bận báo %CPU = 400% — dùng 4 giây CPU trong 1 giây tường, nghe bất khả nhưng đúng: thời gian CPU cộng dồn qua các lõi. sleep dùng 0% CPU dù wall trôi 1 giây; I/O nặng sys 0,64 lớn hơn user 0,36. 'Mất bao lâu' là câu hỏi mơ hồ tới khi bạn hỏi 'wall hay CPU'.
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.