Zombie không phải lỗi của tiến trình con mà của cha không đọc mã thoát. Tôi đo: một vòng waitpid dọn sạch 200 con, còn fork không thu hồi thì cạn 5.000 PID trong 0,17 giây và mọi tiến trình trong container nhận EAGAIN — triệu chứng là 'không tạo được tiến trình' trong khi RAM và CPU vẫn bình thường, đúng chỗ người trực đi tìm sai hướng.
Sao chép giữ dữ liệu tốt cho tới khi máy chính chết và không ai thay nó — Sentinel làm việc thay đó. Đo thật một lần chuyển đổi: Sentinel công bố máy chính mới sau 4,50 giây (≈ down-after + 1,5 giây), nhưng khách hàng ghi liên tục thấy gián đoạn 6,27 giây vì còn phải nhận ra kết nối chết, hỏi lại địa chỉ, nối lại. Vì sao cần ba Sentinel ở ba vùng hỏng, và cái Sentinel không cứu được.
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.
Lua cho bạn tính nguyên tử mà MULTI không cho: đọc một giá trị rồi quyết định dựa trên nó. Đo cái giá: script chạy 3,02 giây thì PING của khách khác chạm 2.951,6 ms — độ chặn gần đúng bằng thời gian chạy, không nhường luồng. Vòng lặp vô hạn không làm máy chủ chết (BUSY sau 5 giây, cứu bằng SCRIPT KILL) nhưng script đã ghi thì không giết được. EVALSHA nhanh hơn EVAL 27%, và cache script sinh động rò 340 MB không ai dọn.
'Chia thành nhiều cụm' nghe như một quyết định kiến trúc. Đo trên hai cụm thật chạy cạnh nhau: mỗi control plane trống tốn 536 MB RAM cố định (nhân với số cụm), và cả hai cụm mặc định của kubeadm dùng chung 10.244.0.0/16 nên pod cụm này không gọi được pod cụm kia — mạng không định tuyến, DNS không biết nhau. Cấp dải IP khác nhau ngay từ khi tạo, vì đổi sau là dựng lại cả cụm.
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'.