Linux 01/09/2026 9 phút

Mở kết nối mới rồi hỏi một câu tốn đúng hai vòng khứ hồi — hỏi cùng câu đó trên kết nối có sẵn tốn một; giữa hai châu lục, khác biệt là 21 mili giây mỗi lần gọi

'Dùng bể kết nối' là lời khuyên ai cũng biết — bài này đo nó đáng bao nhiêu, bằng đơn vị duy nhất mang đi được: vòng khứ hồi. Đo thật cho ba con số rơi đúng vào bội số nguyên của RTT. Trên máy local nó chỉ tiết kiệm một phần tư mili giây, nên không đánh giá nổi ở đó; trong sản phẩm khác vùng, một dịch vụ gọi 20 lượt xuống DB cộng thêm 420 ms chỉ vì không tái dùng kết nối.

Linux 01/09/2026 8 phút

strace -c làm chương trình chậm 446 lần dù nó không in ra một dòng nào — cái giá không nằm ở việc ghi chép, mà ở chỗ mỗi lời gọi phải dừng lại bốn lần

Ai cũng nghĩ 'chỉ đếm thôi' thì nhẹ hơn 'in đầy đủ'. Đo thật: strace -c chậm 446 lần, bản in đầy đủ 501 lần — chênh vỏn vẹn 12%, vì tiền không đi vào chỗ bạn tưởng. Mà trên chương trình không gọi hệ thống thì strace lại miễn phí. Chi phí tính theo số lời gọi, không theo thời gian chạy.

Linux 01/09/2026 8 phút

Tải đĩa thuần đẩy load average từ 8,8 lên 12,88 trong khi CPU người dùng chỉ 1% — và load vẫn hiện 12,65 khi máy đã rảnh hoàn toàn

Ba con số uptime trả về gần như ai cũng đọc sai theo hai kiểu. Thứ nhất: Linux đếm cả tiến trình đợi đĩa, nên load cao không có nghĩa CPU bận — đo được load tăng 4 đơn vị trong khi CPU rảnh 45%. Thứ hai: chúng là trung bình trượt 1/5/15 phút, nói vừa rồi thế nào chứ không nói bây giờ — load còn 12,65 trên máy đã tắt sạch tải. Load để thấy xu hướng, không để chẩn đoán tức thời.

Linux 01/09/2026 7 phút

nice không làm gì cả cho tới khi tôi ghim hai tiến trình vào cùng một nhân — rồi tỉ lệ nhảy thành 98,7 trên 1,3; đây là điều kiện không tài liệu nào nhấn mạnh

CFS chia CPU đều 1/N như nó hứa. Nhưng nice 19 — mức ưu tiên thấp nhất — vẫn nhận đúng một nửa CPU, cho tới khi ép cả hai tiến trình vào cùng một nhân; lúc đó tỉ lệ khớp chính xác bảng trọng số của CFS. Lý do: nice là trọng số trong MỘT hàng đợi chạy, và hai tiến trình ở hai nhân khác nhau không có gì để cân. Trên máy nhiều nhân, nice chỉ có tác dụng khi số tiến trình vượt số nhân.

Linux 01/09/2026 8 phút

Cùng một giá trị giờ, cùng một nguồn: 13,59 ns khi qua vDSO, 154,77 ns khi gọi syscall thẳng — chênh 11 lần, và clock_getres nói dối 24.000 lần

Lấy giờ là thứ mọi log, mọi số liệu, mọi phép đo đều làm. Tôi đo chín cách và tìm ra chênh lệch 11 lần giữa hai cách gọi cùng một hàm (vDSO hay không), một biến thể COARSE rẻ 6 lần đổi lấy độ phân giải 1 ms, và một hàm — clock_getres — báo sai độ phân giải thật tới 24.000 lần. Kèm lỗi kinh điển: dùng REALTIME cho thời hạn.

Linux 01/09/2026 7 phút

SCHED_BATCH nghe như 'chạy khi rảnh' nhưng không nhường CPU một chút nào — còn SCHED_IDLE hạ ưu tiên mạnh gấp bốn lần nice 19, và thời gian thực dừng đúng ở 95%

Bốn cách đổi ưu tiên tiến trình, đo trong đúng điều kiện chúng có tác dụng (hai tiến trình cùng một nhân). Kết quả lật vài trực giác: BATCH vẫn 50/50 vì nó không đụng trọng số, IDLE xuống 0,3% vì nằm ở lớp riêng, và tiến trình thời gian thực bị nhân cố ý chặn ở 95% — tấm lưới duy nhất ngăn một vòng lặp FIFO treo cứng cả máy.