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

DevOps 01/09/2026 9 phút

python:3.12 có 2.889 lỗ hổng, bản alpine cùng Python đó có 25 — ít hơn 115 lần mà không sửa một dòng mã; và đổi ảnh trên cùng một thẻ làm chữ ký biến mất sạch

Pod Security Standards kiểm soát pod LÀM GÌ; bài này lùi một bước, kiểm soát cái NẰM TRONG pod. Quét sáu ảnh: python:3.12 Debian 2.889 lỗ hổng so với python:3.12-alpine chạy cùng Python chỉ 25 — chênh 115 lần chỉ vì mọi thứ đi kèm. Và phép đo quan trọng nhất: chữ ký gắn với digest chứ không với thẻ, nên đổi ruột ảnh dưới cùng một thẻ v1 làm chữ ký mất hoàn toàn. Dùng digest, không dùng thẻ.

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

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.

Backend 01/09/2026 8 phút

Xoá 270.000 khoá khỏi Redis mà RSS không giảm một byte — bộ nhớ trả về theo cả trang, không theo từng khoá, nên xoá rải rác để lại lỗ không thu hồi được

mem_fragmentation_ratio là chỉ số hay bị hiểu sai nhất trong INFO memory. Đo ở ba trạng thái: một instance gần rỗng có tỷ lệ 16,59 mà hoàn toàn khoẻ; xoá 90% khoá thì used_memory tụt còn RSS đứng im ở 107,6 MB vì jemalloc chỉ trả một trang về khi MỌI đối tượng trong đó đã chết. Và activedefrag y, tự nó, thường là lệnh không có tác dụng vì ngưỡng mặc định 100 MB. Cảnh báo trên allocator_frag_bytes, đừng trên tỷ lệ.

Backend 01/09/2026 8 phút

Mở kết nối Redis mới cho mỗi lệnh chậm gấp 5,5 lần — và khi chạm trần 10.000 kết nối, chính redis-cli của bạn cũng không vào nổi để xem chuyện gì đang xảy ra

Bể kết nối là thứ mọi thư viện đều có và ít ai chỉnh. Đo thật: tái dùng kết nối nhanh gấp 5,5 lần mở mới mỗi lệnh (6,4 lần khi có mật khẩu), mật khẩu không làm Redis chậm mà chỉ làm việc MỞ kết nối chậm; mỗi kết nối chỉ tốn 1.928 byte và gần như 0 CPU khi ngồi không — nhưng có một trần cứng 10.000, và lúc chạm nó bạn mất luôn đường nhìn vào bên trong.