Q

Quản trị viên

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.

2300 bài viết · Website
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 10 phút

Cạn sạch 28.232 cổng chỉ trong 22 giây — rồi thêm đúng một dòng recv() làm 'vấn đề biến mất', theo cái cách tệ nhất: đổi lỗi cạn cổng lấy lỗi mất dữ liệu im lặng

Một vòng lặp mở-đóng kết nối tới cùng một đích cạn hết dải cổng phù du trong 22 giây, vì mỗi cổng bị giữ ở TIME_WAIT 60 giây — tiêu nhanh gấp ba lần được trả lại. Ngưỡng thật chỉ ~470 kết nối/giây, thấp hơn trực giác nhiều. Và một dòng mã tưởng như chữa được hoá ra chỉ thay RST vào FIN: một cái bẫy đo lường kinh điển.

Linux 01/09/2026 8 phút

Định dạng một dòng log gần như miễn phí — fsync mỗi dòng đắt gấp 11.464 lần, và một dòng DEBUG đã tắt vẫn ngốn 62 lần chi phí

Ghi log nằm trên đường đi của mọi yêu cầu. Tôi đo sáu cách ghi cùng một dòng: định dạng chuỗi tốn 0,052 µs, còn fsync mỗi dòng tốn 515,903 µs — chi phí không nằm ở chỗ ai cũng tối ưu (định dạng) mà ở mỗi lần dữ liệu *ra khỏi tiến trình*. Kèm cái bẫy đắt nhất: một log.debug đã tắt vẫn dựng chuỗi trước khi bị bỏ, tốn 62 lần so với truyền tham số rời.

DevOps 01/09/2026 8 phút

Sự cố làm 0,2% request chậm gấp 56 lần mà p99 đứng yên ở 0,46 µs — chỉ p99.9 mới lộ ra 21,88 µs

Mở sê-ri quan sát: tôi dựng một sự cố thật (0,2% request đi qua nhánh chậm) rồi soi bằng cả metric, log, trace và đo giá từng lăng kính. p99 mù hoàn toàn vì sự cố nằm gọn trong phần đuôi nó cắt bỏ; trung bình chỉ nhích 12%; ba trụ cột không thay thế nhau — metric nói CÓ, log nói request NÀO, trace nói chậm Ở ĐÂU. Phân vị bạn theo dõi quyết định tỷ lệ sự cố nhỏ nhất bạn thấy được.

DevOps 01/09/2026 8 phút

Trần thật của một node Kubernetes không phải RAM mà là con số 110 — node to gấp đôi không cho gấp đôi số pod, và cụm kind báo 62,4 GiB trên một máy chỉ có 15,6

Đo chi phí bên trong một cụm: bao nhiêu tài nguyên biến mất trước khi ứng dụng đầu tiên chạy. kubelet + containerd 207 MB mỗi node cố định; một pod rỗng tốn 0,44 MB. Nhưng con số đảo ngược trực giác nhất là trần 110 pod/node — độc lập với kích thước node, nên node 16 GB xếp đầy chỉ còn 145 Mi mỗi pod, và pod nhỏ chạm trần SỐ LƯỢNG trước khi chạm trần RAM. Cẩn thận: đo trên kind lạc quan gấp bốn lần vì mỗi node container thấy RAM của cả máy.

Linux 01/09/2026 8 phút

dd báo ghi xong 512 MB sau 0,15 giây ở 3,6 GB/s — năm giây sau, toàn bộ dữ liệu vẫn nằm nguyên trong RAM và chưa một byte nào chạm đĩa

Ở chiều ghi, lời hứa 'đã xong' của nhân là lời hứa suông cho tới khi dữ liệu thật sự xuống đĩa. Đo thật: dd trả về tức thì trong khi 512 MB còn kẹt trong page cache 5–10 giây nữa — cúp điện lúc đó là mất sạch dù ứng dụng đã được báo thành công. Đây cũng là lý do đo tốc độ ghi bằng một lần ghi ngắn không fsync chỉ đo tốc độ của RAM, và luôn cho con số đẹp đến khó tin.