Redis記憶體碎片率

一、記憶體碎片率

mem_fragmentation_ratio = used_memory_rss / used_memory

used_memory ：redis使用其分配器分配的記憶體大小

used_memory_rss ：作業系統分配給redis例項的記憶體大小，表示該程序所佔物理記憶體的大小

兩者包括了實際快取占用的記憶體和redis自身執行所占用的記憶體，used_memory_rss指標還包含了記憶體碎片的開銷，記憶體碎片是由作業系統低效的分配/**物理記憶體導致的。

mem_fragmentation_ratio < 1 表示redis記憶體分配超出了物理記憶體，作業系統正在進行記憶體交換，記憶體交換會引起非常明顯的響應延遲；

mem_fragmentation_ratio > 1 是合理的；

mem_fragmentation_ratio > 1.5 說明redis消耗了實際需要物理記憶體的150%以上，其中50%是記憶體碎片率，可能是作業系統或redis例項中記憶體管理變差的表現

二、記憶體碎片率高的原因

遇到變長key-value負載：儲存的資料長短差異較大，頻繁更新，redis的每個k-v對初始化的記憶體大小是最適合的，當修改的value改變的並且原來記憶體大小不適用的時候，就需要重新分配記憶體。重新分配之後，就會有一部分記憶體redis無法正常**，一直占用著。

maxmemory限制導致key被**刪除

redis寫入大量資料，這些資料的key和原來的資料很多不一致，資料超過maxmemory限制後redis會通過key的**策略將部分舊資料淘汰，而被淘汰的資料本身占用的記憶體卻沒有被redis程序釋放，導致redis記憶體的有效資料雖然沒有超過最大記憶體，但是整個程序的內存在一直增長

info資訊中的evicted_keys欄位顯示的是，因為maxmemory限制導致key被**刪除的數量

key經常需要**，會使客戶端命令響應延遲時間增加，因為redis不但要處理客戶端過來的命令請求，還要頻繁的**滿足條件的key

redis-review.eageye.com集群，執行以來刪除過的key的數量

三、解決方法

限制記憶體交換：如果記憶體碎片率低於1，redis例項可能會把部分資料交換到硬碟上，應該增加可用物理記憶體或減少實redis記憶體占用，設定maxmemory和**策略可以避免強制記憶體交換

重啟redis伺服器：如果記憶體碎片率超過1.5，重啟redis伺服器可以讓額外產生的記憶體碎片失效並重新作為新記憶體來使用，使作業系統恢復高效的記憶體管理。額外碎片的產生是由於redis釋放了記憶體塊，但記憶體分配器並沒有返回記憶體給作業系統

記憶體碎片清理：redis 4.0-rc3 以上版本，使用jemalloc作為記憶體分配器(預設的) 支援記憶體碎片清理

支援在執行期進行自動記憶體碎片清理

設定自動清理 config set activedefrag yes，使用config rewrite 將redis記憶體中新配置重新整理到配置檔案

支援通過命令 memory purge 進行手動清理(與自動清理區域不同)

redis4支援記憶體碎片清理功能使用

記憶體碎片率

原文：