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支持內存碎片清理功能使用

內存碎片率

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

Redis

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。