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
DevOps 02/09/2026 9 phút

Giữ chỉ số một năm không làm dashboard hằng ngày chậm đi một mili-giây — đòn bẩy chi phí thật không phải thời gian giữ, mà là chu kỳ thu thập

Dung lượng tăng tuyến tính theo thời gian giữ, nhưng chi phí truy vấn thì DƯỚI tuyến tính — giữ lâu chỉ làm hoá đơn dài ra, không làm bảng điều khiển chậm. Và đòn bẩy tiết kiệm lớn nhất (15 lần) là chu kỳ thu thập, không phải rút thời gian giữ. Quyết định 'giữ bao lâu' hoá ra hoàn toàn là quyết định về giá trị, không phải kỹ thuật.

#zero-to-hero#quan-sat#devops#giam-sat
28
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.

#he-dieu-hanh#zero-to-hero#hieu-nang#linux
23
Backend 01/09/2026 7 phút

Cùng 199 trường, cùng dữ liệu, nhưng một Hash tốn 16.256 byte còn cái kia 1.840 byte — chênh 8,8 lần chỉ vì một khoá từng phình to rồi co lại

Redis đổi cách mã hoá tập hợp khi nó vượt ngưỡng, nhưng KHÔNG BAO GIỜ đổi ngược. Đo thật: một Hash từng có 513 trường rồi xoá còn 199 vẫn tốn 16.256 byte, gấp 8,8 lần một Hash tạo mới đúng 199 trường (1.840 byte). Đây là rò rỉ bộ nhớ âm thầm nhất trong Redis — phình trong đợt cao điểm rồi giữ chi phí lúc lớn nhất vĩnh viễn. Và một giá trị vượt 64 byte đẩy cả Hash sang mã hoá đắt.

#zero-to-hero#hieu-nang#redis
30
Backend 01/09/2026 8 phút

Đường ống Redis 10.000 lệnh cho 47,9 lần thông lượng — nhưng đẩy lên 100.000 thì tụt còn một nửa; gộp lô có điểm ngọt, không phải càng lớn càng tốt

Phần 2 thấy đường ống cho hơn bốn mươi lần thông lượng trên một kết nối. Bài này tìm điểm dừng: đường ống 10.000 đạt 969.426 ops/s (47,9×), nhưng 100.000 chỉ còn 473.477 — một nửa, vì chi phí đệm ở hai phía vượt phần tiết kiệm round-trip. Bất ngờ hơn: MGET 100 khoá nhanh hơn đường ống 100 lệnh 45% dù cùng một lượt đi về, vì một lệnh phân tích một lần thay vì trăm lần. Và bộ đệm khách thường không có giới hạn (0 0 0).

#zero-to-hero#hieu-nang#redis
33
Backend 01/09/2026 8 phút

Thêm một dòng CREATE INDEX làm truy vấn nhanh hơn 181 lần — tốt hơn cả tỉ lệ trúng cache 99%, và không thêm một hệ thống nào để hỏng

Cache-aside là mẫu dùng Redis phổ biến nhất, nhưng đo thật cho thấy nó thắng ít hơn ta tưởng. Tra khoá chính: Redis GET 0,062 ms ngang PostgreSQL 0,065 ms — đặt cache ở đây chỉ thêm một chỗ để hỏng. Truy vấn đắt 19,9 ms: cache nhanh hơn 321 lần, nhưng một CREATE INDEX kéo nó xuống 0,110 ms — nhanh hơn 181 lần, tốt hơn cả cache trúng 99%. Bộ đệm che một truy vấn chậm; chỉ mục xoá nó.

#zero-to-hero#hieu-nang#redis#postgresql
28