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

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.

Backend 01/09/2026 9 phút

Bốn mươi phép đo Redis gói thành một danh sách kiểm, và ba niềm tin của chính tôi bị con số bác bỏ — cùng ba lần tôi đo sai rồi phải sửa

Chốt sê-ri 40 phần: mười con số đáng nhớ, ba quy luật lặp lại (nút thắt là lượt đi về; vượt ngưỡng là nhảy bậc không tăng dần; Redis chậm dần chứ hiếm khi báo lỗi), một danh sách kiểm chạy được trước khi lên production, và ba lần phép đo của tôi cho kết quả bất khả thi — mỗi lần đều lộ ra vì một con số vượt giới hạn vật lý hoặc không khớp phép đo trước.

Backend 01/09/2026 7 phút

Ảnh Redis chính thức tự tắt protected-mode — tôi chạy FLUSHALL từ một container khác, không mật khẩu, và nó trả về OK

docker run -d redis chạy được ngay, nhưng cấu hình mặc định là cho phòng thí nghiệm, không phải production: không mật khẩu, nghe mọi giao diện, không giới hạn bộ nhớ. Và --memory của Docker không bảo vệ được Redis — đặt nó mà quên maxmemory chỉ đổi cách Redis chết từ 'hết RAM máy chủ' thành 'container bị OOMKilled'. Kèm cấu hình tối thiểu cho môi trường thật, mỗi dòng một lý do đo được.

Linux 01/09/2026 8 phút

Một tiến trình hiện VIRT 2 GB nhưng chỉ tốn 107 MB RAM — và cộng cột %CPU của mọi tiến trình ra 1.600% mà không phải lỗi: mỗi cột trong top trả lời một câu hỏi khác

top là công cụ ai cũng mở đầu tiên, và cột nào cũng có một cách đọc sai. VIRT là chỗ đã đặt trước, không phải RAM đang dùng; %CPU tính theo một nhân nên tổng có thể vượt 100% nhiều lần; và cả RES lẫn %MEM đều đếm trùng bộ nhớ dùng chung nên cộng lại luôn thổi phồng. Con số không trùng lặp là PSS — thứ top không hiện vì tính nó tốn kém.

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ó.

Backend 01/09/2026 9 phút

Cảnh báo trên phần trăm bộ nhớ Redis cho bạn đúng 2 giây báo trước — rồi nó ghim ở 100% và câm lặng trong khi 15.870 khoá bị vứt đi mỗi giây

INFO trả về hơn hai trăm dòng; đo thật trên một Redis 64 MB cho thấy dòng bạn hay cảnh báo nhất — phần trăm bộ nhớ — là dòng vô dụng nhất khi sự cố xảy ra. Nó là chỉ số bão hoà, chạm trần rồi đứng im; cái thật sự nói mức nghiêm trọng là tốc độ đuổi khoá, một con số không có trần. Cùng bốn nguồn để truy một lệnh chậm, và mười chỉ số nên đưa lên bảng.