Từ việc thử nghiệm thêm điều này và đọc về tính bền bỉ của redis, tôi nghĩ có thể thực hiện các nhận xét sau:
- Khi sử dụng RDB (cài đặt mặc định), redis sẽ phân nhánh mỗi lần
save
hoạt động được kích hoạt, (theo mặc định) được đặt thành 15 phút một lần là mức tối thiểu . Khi nhiều lần ghi vào Redis được thực hiện, thì việc ghi RDB thường xuyên như một lần 60 giây . - Mỗi nhánh rẽ sẽ sử dụng phân bổ bộ nhớ "sao chép-ghi-ghi", có nghĩa là trong khi bộ nhớ sẽ không thực sự tăng gấp đôi - nó sẽ xuất hiện như vậy trên các công cụ như
ps
,htop
và những thứ tương tự. - Bản thân fork có thể là một hoạt động đòi hỏi nhiều cpu, đặc biệt là trên các máy chủ ảo dựa trên xen kẽ (đó là những gì chúng tôi đang sử dụng hiện tại).
- Thao tác ghi dường như ghi đè hoàn toàn tệp RDB hiện có. Nó không chỉ viết những thay đổi, mà còn ghi toàn bộ toàn bộ tập dữ liệu vào đĩa.
Vì vậy, trên một máy chủ ảo khiêm tốn với RAM 4Gb và bộ dữ liệu khoảng 750Mb (tại thời điểm tôi đăng câu hỏi), điều này bắt đầu trở nên khá "đắt đỏ". Chúng tôi đã quan sát thấy những mức tăng đột biến của CPU / Bộ nhớ, cũng như IO tăng lên, ngay cả khi sử dụng tải / redis khá vừa phải.
Vì vậy, để trả lời câu hỏi của riêng tôi - đây có vẻ là hành vi "được mong đợi".
Để cải thiện tình hình, chúng tôi đã chọn chuyển cấu hình của mình sang sử dụng kết hợp RDB và AOF. AOF (Chỉ thêm tệp), dường như chỉ ghi thay đổi vào đĩa. Bạn vẫn có thể (và nên) định cấu hình tệp AOF để viết lại (sử dụng auto-aof-rewrite-percentage
và auto-aof-rewrite-min-size
cài đặt). Cũng nên sử dụng RDB cho các ảnh chụp nhanh. Tuy nhiên, trong cấu hình này, bạn có thể viết lại toàn bộ / chụp nhanh ít thường xuyên hơn và vẫn duy trì hiệu suất khá tốt và độ bền thậm chí còn tốt hơn.