Linux 01/09/2026 9 phút

Cùng một lần đọc RAM tốn 156 ns hoặc 5 ns — chênh 28 lần chỉ tuỳ vào việc CPU có đoán được địa chỉ tiếp theo hay không; tối ưu bộ nhớ đệm không phải đọc ít đi

Con trỏ nối đuôi cho thấy cầu thang L1→RAM chênh 108 lần. Nhưng phép đo thứ hai lật kèo: cùng 256 MB, cùng kiểu trượt cache, các lần đọc độc lập nhanh gấp 28 lần các lần đọc phụ thuộc nhau — vì CPU hiện đại giữ hàng chục yêu cầu bộ nhớ cùng lúc. Nên std::vector<Item> và std::vector<Item*> chứa cùng dữ liệu chênh nhau một bậc độ lớn, và không profiler nào chỉ vào dòng khai báo đó.

Backend 01/09/2026 7 phút

Memcached đọc nhanh hơn Redis 55% và tốn ít bộ nhớ hơn 61% cho cùng một bộ đệm — nhưng khởi động lại là mất sạch, và đó mới là chỗ quyết định

Đo cả hai trên đúng cùng bài toán khoá–giá trị 100 byte. Không đường ống thì bằng nhau (nút thắt là lượt đi về). Đẩy mạnh thì Memcached thắng vì đa luồng thật, và tốn ít RAM hơn 2,6 lần vì không có lớp đối tượng đa kiểu. Nhưng nó không có lưu trữ, trần 1 MB mỗi giá trị, và không có kiểu dữ liệu nào. Câu hỏi không phải cái nào nhanh, mà là bạn sẽ cần gì trong sáu tháng tới.

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

Tải đĩa thuần đẩy load average từ 8,8 lên 12,88 trong khi CPU người dùng chỉ 1% — và load vẫn hiện 12,65 khi máy đã rảnh hoàn toàn

Ba con số uptime trả về gần như ai cũng đọc sai theo hai kiểu. Thứ nhất: Linux đếm cả tiến trình đợi đĩa, nên load cao không có nghĩa CPU bận — đo được load tăng 4 đơn vị trong khi CPU rảnh 45%. Thứ hai: chúng là trung bình trượt 1/5/15 phút, nói vừa rồi thế nào chứ không nói bây giờ — load còn 12,65 trên máy đã tắt sạch tải. Load để thấy xu hướng, không để chẩn đoán tức thời.

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.