内存碎片过高优化的功能和原理

文章系转载，方便整理和归纳，源文地址 https://juejin.cn/post/6989526481709826055

内存碎片率公式

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。

解决方法

• 限制内存交换： 如果内存碎片率低于1，Redis实例可能会把部分数据交换到硬盘上，应该增加可用物理内存或减少实Redis内存占用，设置maxmemory和回收策略可以避免强制内存交换。
• 重启Redis服务器：如果内存碎片率超过1.5，重启Redis服务器可以让额外产生的内存碎片失效并重新作为新内存来使用，使操作系统恢复高效的内存管理。
• 额外碎片的产生是由于Redis释放了内存块，但内存分配器并没有返回内存给操作系统。
• 内存碎片清理：Redis 4.0-RC3 以上版本，使用jemalloc作为内存分配器(默认的) 支持内存碎片清理，支持在运行期进行自动内存碎片清理。
  • activedefrag yes 开启自动内存碎片整理(总开关)：设置自动清理 config set activedefrag yes，使用config rewrite将redis内存中新配置刷新到配置文件。
  • redis4.0 以上可以使用新增指令来手动回收内存碎片，配置监控使用性能更佳。
    • 支持通过命令 memory purge 进行手动清理(与自动清理区域不同)

---

查看当前的内存碎片率, 这时碎片率(mem_fragmentation_ratio)很高 : 1.54, 意味着54%的内存浪费

$ redis-cli -p 6383 info memory
# Memory
used_memory:1073741736
used_memory_human:1024.00M
used_memory_rss:1650737152
used_memory_rss_human:1.54G
used_memory_peak:1608721680
used_memory_peak_human:1.50G
used_memory_peak_perc:66.75%
used_memory_overhead:253906398
used_memory_startup:766152
used_memory_dataset:819835338
used_memory_dataset_perc:76.41%
total_system_memory:67535904768
total_system_memory_human:62.90G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:1073741824
maxmemory_human:1.00G
maxmemory_policy:allkeys-lru
mem_fragmentation_ratio:1.54
mem_allocator:jemalloc-4.0.3
active_defrag_running:0
lazyfree_pending_objects:0
复制代码

---

开启自动内存碎片整理

$ redis-cli -p 6383 config set activedefrag yes
OK
$ redis-cli -p 6383 config rewrite
复制代码

进行手动清理

$ redis-cli -p 6383 memory purge
复制代码

实际案例

并发场景：

• 每日高达1600W次hmset写入操作，且value长短不一（有效期：24小时）；
• 每日上述hmset写入操作对应的key是不一样的；

常见场景：

• 写负载高，尤其批量删除操作；
• 存储的K-V值，长短不一，差异较大。

综合解决方案：

• 目前没有什么实际方案好于重启。
• 有条件扩大内存大小。
• 添加内存监控，当内存使用率到阈值之后重启redis，回收内存

在2017年1月1日已经提交pr了, 相关地址: github.com/antirez/red…

配置说明:

# Enabled active defragmentation
# 碎片整理总开关
# activedefrag yes
 
# Minimum amount of fragmentation waste to start active defrag
# 内存碎片达到多少的时候开启整理
active-defrag-ignore-bytes 100mb
 
# Minimum percentage of fragmentation to start active defrag
# 碎片率达到百分之多少开启整理
active-defrag-threshold-lower 10
 
# Maximum percentage of fragmentation at which we use maximum effort
# 碎片率小余多少百分比开启整理
active-defrag-threshold-upper 100
 
# Minimal effort for defrag in CPU percentage
active-defrag-cycle-min 25
 
# Maximal effort for defrag in CPU percentage
active-defrag-cycle-max 75