Linux 01/09/2026 8 phút

Một hệ thống nghẽn đĩa hiện CPU rảnh 3% — nhìn nhanh tưởng CPU đang bận, thực ra 94% thời gian đó nó ngồi không chờ đĩa trả lời

Mở đầu sê-ri 50 phần về hiệu năng Linux. Bốn kiểu nghẽn — CPU, đĩa, bộ nhớ, chuyển ngữ cảnh — trông giống nhau nếu chỉ nhìn một con số, và cái này giả trang thành cái kia. Đo thật cả bốn: nghẽn đĩa cho CPU rảnh 3% (nhưng 94% là chờ), nghẽn khoá đẩy chuyển ngữ cảnh lên 964.760 lần/giây. Một quy trình sáu bước đọc vmstat để không mua nhầm CPU cho một máy nghẽn đĩa.

Linux 01/09/2026 8 phút

Đọc ngẫu nhiên qua bộ đệm trang nhanh gấp 15 lần đi thẳng xuống NVMe — và một máy chủ khoẻ mạnh luôn có RAM trống gần bằng 0, đó là điều đúng đắn chứ không phải triệu chứng

Bộ đệm trang là thứ làm 'available' khác 'free'. Đo thật: cùng lần đọc 4 KB ngẫu nhiên, qua bộ đệm 425.874 IOPS còn O_DIRECT chỉ 28.655 — 15 lần. Và bộ đệm ăn thêm nửa gigabyte trong khi RAM khả dụng gần như không đổi, vì trang bộ đệm sạch vứt đi lúc nào cũng được. RAM trống là RAM lãng phí. Cộng thêm một sai lầm đo lường: drop_caches không chạm tới máy chủ bên dưới.

Linux 01/09/2026 9 phút

Đọc 64 byte từ một tệp đã nằm sẵn trong RAM: pread mất 1.019 ns, mmap mất 19 ns — 53 lần, mà không bên nào chạm đĩa; toàn bộ khác biệt là cái giá đi vào nhân

mmap cho phép đọc một tệp như đọc một mảng trong bộ nhớ. Đo thật: với nhiều lần đọc nhỏ ngẫu nhiên trên tệp nóng, mmap nhanh 53 lần vì đọc một byte là đúng một lệnh máy, không lời gọi hệ thống nào. Nhưng nó không phải mặc định — lỗi I/O đến dưới dạng SIGBUS giữa một lệnh truy cập trông vô hại, và đó là lý do SQLite lẫn PostgreSQL từ chối dùng nó cho tệp dữ liệu chính.

Linux 01/09/2026 9 phút

Chương trình giải phóng sạch 400.000 khối, hệ điều hành vẫn thấy nó ôm 410 MB — một lời gọi malloc_trim trả lại 95 lần, và chênh 1 KB kích thước khối quyết định 200 MB có về hay không

Phần lớn 'rò rỉ bộ nhớ' được báo trong dịch vụ chạy lâu ngày thực ra không rò rỉ gì: bộ nhớ đã được free đúng cách, chỉ nằm lại trong bộ cấp phát của tiến trình thay vì quay về nhân. Đo thật cho thấy một ngưỡng 128 KB khiến chênh đúng 1 KB kích thước khối tạo khác biệt 175 lần, và cách phân biệt rò rỉ thật với phân mảnh trong vài dòng mã.

Linux 01/09/2026 9 phút

Cách chữa 'Too many open files' được nhắc nhiều nhất — ulimit -n 65536 — thường không làm điều bạn nghĩ: giới hạn mềm ai cũng tự nâng, và nâng nó lên có khi làm chương trình hỏng nặng hơn

Giới hạn mềm không phải một hàng rào, nó là giá trị khởi đầu — tiến trình tự nâng lên tới giới hạn cứng mà không cần quyền gì (đo được: gấp 1.027 lần). Một triệu mô tả tệp chỉ tốn 38 MB nên đặt thấp để 'tiết kiệm bộ nhớ' là vô nghĩa. Và cú bất ngờ nhất: nâng ulimit khiến một dịch vụ dùng select() hỏng ở tận đâu đâu, hàng giờ sau, chỉ khi tải cao.

Linux 01/09/2026 9 phút

perf báo 62,65% cho hàm thật sự chiếm 62,50% — sai đúng 0,15 điểm mà không quấy rầy chương trình một nhịp nào; đây là điều tra chọn mẫu áp vào code

strace làm chậm 446 lần vì nó chặn từng lời gọi. perf đứng ở đầu kia của thang: nó chỉ thỉnh thoảng ngắt ra ghi con trỏ lệnh đang ở đâu, rồi đếm — chi phí không đo được, mà bốn hàm vẫn xếp hạng đúng tới 0,15 điểm phần trăm. Cùng logic thăm dò ý kiến: đủ mẫu ngẫu nhiên là tỷ lệ hội tụ về sự thật.