Redis的記憶體片段，Redis記憶體片段

Redis的記憶體片段，Redis記憶體片段

Redis預設使用jemalloc分配記憶體，根據fast'14的最佳論文的說法，當遇到變長key-value負載時，會出現片段問題：記憶體利用率低，實際分配的記憶體比所需要的記憶體多。因此我用YCSB對Redis的記憶體進行了測試。

• 實驗的第1階段：向Redis插入100萬條記錄，key為20位元組，value為100位元組，皆為定長，理論上的有效資料大約是120MB。
• 階段2：產生90萬個update請求，請求為均勻隨機分布（每個key被選中的機率相等），key值不變，但value變為130位元組。一次update相當於刪除原來的100位元組，再插入一個130位元組。
• 階段3：產生90萬個update請求，value變為170位元組。
• 階段4：產生90萬個update請求，value變為210位元組。
• 接著12個階段，每次都是90萬個update請求，value長度漸增。
• 最後一個階段不產生任何請求，重啟redis。

然後每一階段結束後，都使用info命令查看redis的記憶體情況，結果如所示。

used代表redis使用jemalloc分配的記憶體，rss代表了進程當前佔用的記憶體（可以看做jemalloc實際分配了多少記憶體）。rss/used可以作為衡量片段的指標，越大說明片段越嚴重。

可以看到隨著value不斷增大，redis需要分配的記憶體線性增長。rss的增長比used更快，因此記憶體片段的問題的確存在，rss/used甚至一度超過了2.0（440位元組時達到最高值為2.06），這意味著redis每用1GB記憶體都需要額外多付出1GB。頂峰過後，rss/used下降到了1.6左右。如果我們重啟redis，片段將不再存在。

一個值得注意的問題是，redis使用的記憶體比實際的資料量多很多。比如第一階段後，有效資料應為120MB，但redis卻分配了525.4MB的記憶體。其它階段也有類似現象。具體原因還不清楚，但我感覺有點多。因此除了jemalloc存在的片段問題，redis本身是否在使用記憶體時過於土豪？

我還嘗試測試了千萬條記錄的實驗，測試方法和百萬記錄完全一致。但在我的16GB記憶體的伺服器上，實驗幾乎無法進行，在第2、3個階段時，redis就會報無法分配記憶體的錯誤，導致實驗失敗。我的猜測是redis的rdb機制使用了copy-on-write，在我們這麼高的update負載下，redis需要兩倍記憶體才能完成rdb。

因此我關閉了rdb再進行實驗。這次實驗可以跑到第8個階段（370位元組），但在第9個階段時，出現無法分配記憶體的錯誤，因為redis使用的記憶體超過了實體記憶體。我們來看看第9個階段的有效資料量，最壞的情況是900萬個410+20的key value，100萬個370+20的key value，差不多4GB的資料量。但redis在關閉rdb的情況下卻無法完成任務！（考慮到這時rss/used接近2了，就算沒有任何開銷，也需要8GB的記憶體）

實際的情況是：上述的實驗有一些極端，實際的負載可能沒有這麼變態。因此我測試了facebook公布的負載（即key的長度服從極值分布，value的長度服從帕累托分布），結果發現jemalloc沒有出現任何記憶體片段問題，rss/used一直是1.03左右。因此記憶體片段問題可能存在，但有多嚴重，得看負載。

redis 最大記憶體 多大

redis 的最大佔用記憶體數取決於
你機器的記憶體有多大。
你在設定檔中給參數maxmemory分配了多大的空間。

 
redis選擇aof持久化的時 只可以用到一半的maxmemory？

可能在持久化操作時要用到fork出的新進程，子進程完全拷貝了父進程，maxmemory可能是指所有進程的memory，所以只有一半記憶體。