内存碎片率公式
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
