Lưu trữ — Tháng 9/2026

1676 bài viết
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.

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

Khởi động lại Redis: script Lua biến mất sạch, còn Function vẫn nguyên vẹn và chạy được ngay — nhưng tốc độ hai bên giống hệt nhau, vì cùng một máy Lua

Redis 7 thêm Functions, và câu hỏi đầu tiên ai cũng hỏi là 'khác gì Lua script'. Đo cả hai trên cùng logic: sau khi khởi động lại, EVALSHA trả NOSCRIPT còn FCALL chạy bình thường — vì function nằm trong chính dữ liệu, đi theo RDB/AOF/bản sao, còn script chỉ nằm trong bộ nhớ tạm. Nhưng FCALL 20.520 ops/s so EVALSHA 20.256, chênh trong nhiễu: đừng chuyển vì hiệu năng, chuyển vì vận hành — cờ no-writes được thi hành thật, tên có nghĩa thay mã băm, và mã đi theo quy trình triển khai.

#zero-to-hero#redis
20
Backend 01/09/2026 8 phút

Giết Redis bằng SIGKILL với appendfsync=no — mất đúng 0 bản ghi, lặp ba lần vẫn vậy; vì tiến trình chết không phải mất điện, và người ta hay nhầm hai thứ đó

AOF ghi từng lệnh vào tệp thay vì chụp ảnh định kỳ, với ba chế độ appendfsync ai cũng gọi là nhanh/cân bằng/an toàn. Đo cả tốc độ lẫn lượng mất thật: no và everysec nhanh ngang nhau, always chậm 12,5 lần khi gọi từng lệnh nhưng chỉ 4,8 lần khi có đường ống. Bất ngờ lớn nhất: SIGKILL Redis với appendfsync=no vẫn mất 0 — vì write() đã vào bộ đệm kernel, và giết tiến trình không xoá được nó. appendfsync chỉ quyết định chuyện gì xảy ra khi mất điện.

#hieu-nang#zero-to-hero#redis
21
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.

#devops#zero-to-hero#quan-sat#giam-sat
22
Backend 01/09/2026 8 phút

Ghi đè 7 triệu khoá trong lúc Redis đang chụp ảnh bộ nhớ làm chi phí copy-on-write nhảy từ 1,4 MB lên 87 MB — và INFO memory không hề thấy một byte nào trong đó

RDB chụp toàn bộ bộ nhớ Redis ra một tệp. Đo thật: BGSAVE 2 triệu khoá xong trong 1,21 giây, tệp nén 7,2 lần nhỏ hơn bộ nhớ, khách gần như không thấy độ trễ nhờ fork. Nhưng chi phí thật nằm ở copy-on-write: không ghi gì thì tốn 1,4 MB, ghi đè 7 triệu khoá lúc đang chụp thì tốn 87 MB — gấp 64 lần — và used_memory_rss của Redis đứng im vì các trang bị sao chép thuộc về tiến trình con. Đây là nguồn gốc lời khuyên 'chỉ dùng 50% RAM cho Redis'.

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

Giết máy chính Redis giữa 2,7 triệu lệnh ghi: mất 0 — nhưng để bản sao chậm lại một chút rồi mới giết: mất 79%; 'bất đồng bộ' không có nghĩa 'mất một ít'

Sao chép của Redis là bất đồng bộ, và mọi tài liệu đều cảnh báo điều đó nghĩa là mất dữ liệu. Đo thật: liên kết khoẻ thì giết máy chính giữa 2,78 triệu lệnh vẫn mất đúng 0; nhưng cho bản sao chậm lại trước khi giết thì mất 79.592 trên 100.719 lệnh — gần bốn phần năm. Lượng mất không phải 'vài lệnh cuối', nó bằng ĐÚNG khoảng cách bản sao đang chậm ngay lúc đó. WAIT thu hẹp khoảng đó nhưng chậm 25 lần.

#hieu-nang#zero-to-hero#redis
18