Redis內存碎片率

1、 內存碎片率
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實例中內存管理變差的表現

2、 內存碎片率高的緣由
遇到變長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的數量
3、 解決方法
限制內存交換： 若是內存碎片率低於1，Redis實例可能會把部分數據交換到硬盤上，應該增長可用物理內存或減小實Redis內存佔用，設置maxmemory和回收策略能夠避免強制內存交換
重啓Redis服務器：若是內存碎片率超過1.5，重啓Redis服務器可讓額外產生的內存碎片失效並從新做爲新內存來使用，使操做系統恢復高效的內存管理。額外碎片的產生是因爲Redis釋放了內存塊，但內存分配器並無返回內存給操做系統
內存碎片清理：Redis 4.0-RC3 以上版本，使用jemalloc做爲內存分配器(默認的) 支持內存碎片清理
支持在運行期進行自動內存碎片清理
設置自動清理 config set activedefrag yes，使用config rewrite 將redis內存中新配置刷新到配置文件
支持經過命令 memory purge 進行手動清理(與自動清理區域不一樣)

redis4支持內存碎片清理功能使用
內存碎片率

原文：https://blog.csdn.net/my_tiantian/article/details/84333716