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 9 phút

Bốn sự cố khác hẳn nhau cùng cho ra một câu 'dịch vụ chậm' — nproc và loadavg không phân biệt nổi cái nào, còn một dòng cat thì chỉ đúng thủ phạm

Tôi dựng bốn hoàn cảnh khác nhau, tất cả đều biểu hiện thành 'hệ thống ì', rồi xem chỉ số nào tách được chúng. nproc trả 10 ở cả bốn, loadavg đo nhầm cả máy chủ; còn cpu.stat và PSI phân biệt tuyệt đối. Bonus: bị bóp CPU 0,3 nhân không chỉ chậm 6 lần mà còn tốn 1,81 lần CPU cho cùng một việc.

Backend 01/09/2026 8 phút

Cửa sổ cố định cho 200 yêu cầu lọt qua trong 0,3 giây dù giới hạn là 100/giây — và cách đếm chính xác tuyệt đối ngốn gấp 1.646 lần bộ nhớ để sửa đúng 2% sai số

Giới hạn tần suất là ứng dụng phổ biến thứ hai của Redis sau cache. Cài bốn thuật toán bằng Lua rồi đo cả tốc độ, bộ nhớ lẫn độ chính xác: cửa sổ cố định đơn giản nhất nhưng để lọt gấp đôi ở ranh giới; nhật ký trượt chính xác tuyệt đối nhưng tốn 88 GB nơi cửa sổ trượt chỉ tốn 53 MB với sai số 2%. Bài học là chọn xấp xỉ đủ tốt, không đuổi theo chính xác tuyệt đối.

Linux 01/09/2026 9 phút

Thêm 20 ms độ trễ mà không mất gói nào: 10.403 tụt còn 150 MB/s — rồi làm mất đúng 1% số gói, nó về 4 MB/s; mất gói không lấy đi 1% dữ liệu, nó đánh sập cửa sổ tắc nghẽn

Cùng máy, cùng phần mềm, chỉ đổi đường truyền bằng tc netem. Độ trễ một mình lấy đi 69 lần thông lượng vì TCP phải chờ ACK sau mỗi cửa sổ. Rồi mất một phần nghìn số gói làm mọi thứ chậm 40 lần — vì CUBIC cắt đôi cửa sổ mỗi lần mất gói và không kịp lớn lại. Câu 'chỉ mất có 1% thôi' trong báo cáo sự cố nguy hiểm hơn nó nghe.

DevOps 01/09/2026 8 phút

Cùng một dòng log: print tốn 0,18 µs, logging tốn 4,51 µs — và 94% khoản chênh không nằm ở chỗ ai cũng nhắm vào khi tối ưu

Năm cách ghi cùng một dòng log trong Python, đo trên máy thật: khoảng cách 25 lần giữa print và logging, và khi bóc tách thì định dạng thời gian chỉ chiếm 17% — 94% chi phí biến vào bộ khung dựng LogRecord. Kèm hai phát hiện: lời gọi bị lọc bỏ rẻ tới 82 lần, nhưng chỉ khi bạn không dùng f-string.

Linux 01/09/2026 7 phút

Cùng một lời gọi fsync, cùng một ổ đĩa: 750.000 IOPS trên RAM, 686 khi bắt nó thật sự bền — hơn một nghìn lần chênh nhau, và bạn chọn được mình đứng đâu

fsync là chỗ trả tiền cho lời hứa của write. Tôi đo nó trên bốn đích đến (tmpfs, ext4 tắt/bật rào chắn, overlay container) và thấy khoảng cách nghìn lần; rồi cho thấy một đòn bẩy trong tay ứng dụng — dồn ghi trước khi fsync — kéo thông lượng lên 79 lần. Đây là cùng cơ chế commit theo nhóm mà mọi cơ sở dữ liệu đều dùng.

Linux 01/09/2026 9 phút

ext4 báo 'hết ổ đĩa' khi vẫn còn trống 71% — nó hết một thứ khác mà df -h không hề nhắc tới, và đây là một trong những sự cố khó chẩn đoán nhất trên máy chủ

Tạo tệp rỗng trên ext4 tới khi No space left on device — mà dung lượng còn dư 71%. Thủ phạm là inode: ext4 chốt cứng số lượng lúc mkfs, hết inode là hết tệp bất kể còn bao nhiêu GB. Cộng thêm bảng đo chi phí stat theo tầng liên kết mềm, trần chuỗi đúng 40, và một sai lầm đo lường tôi tự vấp: stat không đi theo liên kết.