Linux 01/09/2026 8 phút

Vượt giới hạn bộ nhớ đúng 17% làm giá mỗi trang nhảy từ 0,01 lên 4,82 µs — gần 500 lần, không có bậc trung gian; và cái bẫy thật của swap là nó giữ tiến trình sống thoi thóp thay vì cho chết hẳn

Có nên tắt swap không — câu này được tranh cãi nhiều hơn được đo. Đo thật: không swap thì vượt giới hạn là bị giết ngay; có swap thì tiến trình sống, health check vẫn 200, dashboard vẫn xanh, mà mỗi yêu cầu chậm 500 lần. Không cảnh báo nhị phân nào bắt được trạng thái đó. Đây là lý do Kubernetes mặc định đòi tắt swap — và vì sao vẫn nên giữ nó với swappiness thấp.

Linux 01/09/2026 8 phút

Đo một lần, ext4 nhanh gấp 3,2 lần xfs — đo ba lần, con số đó bốc hơi thành nhiễu; bốn phép đo cho bốn thứ hạng khác nhau, và không hệ tệp nào thắng cả bốn

Ba hệ tệp, cùng một máy, cùng một bộ phép đo. Lần chạy đầu tiên cho một tỷ lệ đẹp, dễ nhớ, dễ giật tít — và sai hoàn toàn: chạy lại ba lần thì hai dải trùm lên nhau. btrfs kém rõ ở fsync vì sao chép khi ghi, ext4 ổn định nhất nên vẫn là mặc định cho cơ sở dữ liệu, còn câu hỏi 'hệ tệp nào nhanh hơn' thì không có câu trả lời — phải hỏi nhanh hơn ở việc gì.

Linux 01/09/2026 9 phút

Container không lấy đi 3% CPU của tôi — nhưng chạy nhầm kiến trúc làm memset chậm đi 174 lần, và không có 'hệ số emulation' nào cả

Cùng một file C, cùng cờ -O2, chạy ở ba nơi trên một chiếc M4: chạy thẳng, container arm64, container x86_64. Cái vỏ container gần như miễn phí với CPU và bộ nhớ. Nhưng phiên dịch kiến trúc tính tiền từ 1,76 lần tới 174 lần trong CÙNG một chương trình — không tóm tắt được thành một con số.

Linux 01/09/2026 8 phút

Cấu hình container dừng nhanh nhất — 113 ms — lại là cấu hình duy nhất mất dữ liệu: nó bỏ qua sạch bước dọn dẹp

Mọi container bị dừng thường xuyên hơn bị lỗi. Tôi đo sáu cách đóng gói cùng một ứng dụng: cái dừng trong 113 ms trông đẹp nhất trên bảng điều khiển nhưng là cái duy nhất không chạy dọn dẹp. Dừng nhanh không phải dừng êm — chỉ số đúng là mã thoát 0 cộng bằng chứng trong log, và hai lỗi đóng gói khác nhau cho cùng một triệu chứng.

Linux 01/09/2026 8 phút

Cùng một lượng đọc đĩa, iowait đi từ 35% xuống 4% chỉ vì tôi cho CPU thêm việc — chỉ số 'chờ I/O' thấp không hề chứng minh đĩa không nghẽn

Ba con số us, sy, wa có trong mọi công cụ đo Linux, và mỗi loại tải để lại một dấu vết riêng. Nhưng phép đo quan trọng nhất bài là chỗ wa nói dối: giữ nguyên tải đĩa, thêm 14 tiến trình tính toán, iowait tụt từ 35 xuống 4 trong khi số tiến trình bị chặn ở I/O không đổi một chút nào. Trên máy chủ đầy tải, wa gần như luôn thấp — đúng lúc cần nó nhất thì nó im.