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.
/proc không phải file trên đĩa — nhân sinh nội dung tại chỗ mỗi lần đọc (nên stat báo 0 byte). Tôi đọc /proc/self/stat để xem CPU mình tăng, mãi được 0/0: self là kẻ đang đọc, không phải chương trình tôi nghĩ. Bốn trạng thái R/S/D/Z và cách chẩn đoán không cần cài gì.
Container thấy 10 lõi nhưng cgroup chỉ cho dùng 2: 8 luồng bận chỉ đạt 4 giây-lõi thay vì 16, bị đóng băng 20/21 chu kỳ. nproc vẫn nói dối là 10. App 'chậm' dù host rảnh là bị throttle — chẩn đoán bằng cpu.stat chứ không bằng nproc/top, và đặt thread pool theo quota cgroup.
Viết WHERE diem <> 7 để lấy mọi hàng không phải 7, đợi 990000, đo ra 790000 — 200000 hàng NULL biến mất lặng lẽ. NULL không phải giá trị, so sánh với nó ra 'unknown' và WHERE loại sạch. NOT IN với một NULL trả 0 hàng, AVG bỏ NULL, và hàng toàn NULL còn nhỏ hơn trên đĩa. Logic ba trạng thái của SQL, đo tận nơi.
Mỗi .c dịch một mình, không thấy các file khác; linker khớp theo tên chứ không theo kiểu. Một lệch kiểu xuyên file lọt lưới cả trình dịch lẫn linker — chỉ -flto bắt được. Đo thật trong container.
Ai cũng biết compiler tính sẵn 2+3 thành 5. Tôi đo xem nó đi xa tới đâu: cùng một hàm ba phép nhân, khi đầu vào là hằng 100 thì gcc gấp toàn bộ thành một literal 64-bit (5 lệnh, 0 phép nhân, 0 ns); khi đầu vào từ volatile thì phải tính đủ (22 lệnh, 3 phép nhân, 0,99 ns). Ranh giới nằm ở một câu hỏi.
Tổng kết 45 phần đo thật hệ điều hành trong container Linux: một thang độ trễ trải ~36.000 lần (từ 0,25ns đọc RAM tuần tự tới 9µs đánh thức luồng), và bốn mẫu trực giác-sai lặp đi lặp lại — chi phí per-thao-tác, cái đắt là phải ngủ, cấp phát lười, đoán được hơn nhanh thô.