redis內存和cpu尖峯

我們在我們的應用中使用redis作爲一些數據，它非常棒。我注意到redis-server進程中偶爾會出現cpu和內存峯值。redis內存和cpu尖峯

Process and memory monitoring on our Giraffe dashboard

這是從我們的生產和暫存環境Giraffe dashboard。舞臺顯然不那麼繁忙，但生產不是很忙，要麼通常...

這似乎與後臺保存相關，但與所有這些都不相關。只有少數人創造了這個高峯。也許都行，但這只是測量分辨率的問題（有些根本不在我們的內存/ CPU監控週期中）。我不完全確定。

我還在想這是否是預期的/正常的。我們沒有觀察到任何問題，但我想保持安全。如果我們的生產有更多的流量/活動，我們是否會看到更多像這樣的尖峯？

UPDATE：

Redis的日誌文件圍繞尖峯時間

[18588] 05 May 11:42:51.004 * 10 changes in 300 seconds. Saving... 
[18588] 05 May 11:42:51.258 * Background saving started by pid 32712 
[32712] 05 May 11:43:00.511 * DB saved on disk 
[32712] 05 May 11:43:00.549 * RDB: 1 MB of memory used by copy-on-write 
[18588] 05 May 11:43:00.629 * Background saving terminated with success

來源

2013-05-05 gingerlime

從這個進一步的實驗和閱讀redis persistence，我認爲以下意見可以提出：

當使用RDB（默認設置），Redis的將每一個save操作被觸發時叉，這（默認情況下）設置爲每15分鐘至少。當執行更多對Redis的寫入操作時，RDB寫入頻率爲每60秒。
每個分支將使用「寫入時複製」內存分配，這意味着雖然內存不會實際增加兩倍，但它會出現在類似ps,htop等工具上。
分叉本身可以是一個相當cpu密集型操作，particularly on xen-based virtual hosts（這是我們目前使用的）。
寫操作好像是完全覆蓋了現有的RDB文件。它不會只寫入更改，而是將整個數據集轉儲到磁盤。

因此，在4Gb RAM和數據集大約750Mb的虛擬主機（在發佈問題時），這開始變得相當「昂貴」。我們觀察到CPU /內存峯值以及IO增加，即使在相當適中的加載/ redis使用情況下也是如此。

所以要回答我自己的問題 - 這似乎是「預期」的行爲。

至於改善情況，我們選擇將配置切換爲使用RDB和AOF的組合。 AOF（僅附加文件），似乎只將更改爲寫入磁盤。您可以（也應該）仍然配置AOF文件以進行重寫（使用auto-aof-rewrite-percentage和auto-aof-rewrite-min-size設置）。還建議仍然使用RDB進行快照。然而，在這種配置中，你可能不太經常做完整的重寫/快照，並且仍然保持非常好的性能和更好的耐久性。

來源

2013-07-07 17:00:36 gingerlime