Redis INFO memory 怎么看碎片率：allocator_frag_ratio、峰值与回收验证

Redis 的 key 数量没明显增加，业务侧看着也不忙，但进程 RSS 却一直降不下来，这种现场很容易被一句“内存碎片高”带过。真正排查时，先看 INFO memory 的字段关系，再决定是暂时观察、安排回收，还是回到对象生命周期上找原因。

先把 Redis 的“用了多少”和“占了多少”分开

used_memory 更接近 Redis 数据结构和内部对象使用的内存，used_memory_rss 则是进程从操作系统视角占住的常驻内存。两者的差值可能来自分配器保留的活动页、已释放但尚未归还的页，也可能只是刚经历过一轮峰值。

排查时不要只抄一个比例。可以在同一时间窗口连续采样：

redis-cli INFO memory | egrep 'used_memory:|used_memory_rss:|allocator_allocated:|allocator_active:|allocator_resident:|allocator_frag_ratio:|mem_fragmentation_ratio:'

这张图把字段放在同一条判断线上：先看工作集，再看分配器活动内存，最后才解释 RSS 与比例。

原架构的瓶颈：一次快照解释不了内存峰值

线上批量导入、排行榜重建或大批量过期，都会让对象分配和释放在短时间内集中发生。此时看到的 RSS 可能仍然是峰值后的残留，单次快照无法回答“正在增长”还是“已经稳定”。

建议固定采样间隔，覆盖一次业务高峰和高峰后的平稳期：

date '+%F %T'
redis-cli INFO memory | egrep 'used_memory:|used_memory_rss:|allocator_active:|allocator_resident:|allocator_frag_ratio:'

如果 used_memory 和 allocator_active 一起上升，问题更像工作集或分配活动增长；如果前者回落而后者保持高位，才有必要继续看碎片和回收路径。这里别急着改参数。

按顺序做一次低风险判断

第一步：确认差值是不是持续存在

先记录三次以上快照，确保业务负载大致相同。计算时只做方向判断，不要把两个字段的差值直接叫作碎片：

RSS 差值 = used_memory_rss - used_memory
分配器差值 = allocator_active - allocator_allocated

如果差值随着业务工作集一起变大，应该先查对象数量、批量命令和过期节奏；如果工作集稳定但分配器差值长期不回落，再进入回收评估。

第二步：确认分配器类型和回收能力

不同构建方式、分配器和运行环境，对内存页的保留行为并不一样。先把 mem_allocator 记下来，再查当前 Redis 版本对应的内存管理能力。不要看到 allocator_frag_ratio 就默认所有实例都能用同一种回收命令。

第三步：在低峰做前后对照

当业务允许、并且已经保留了基线后，再安排一次回收动作。Redis 官方文档将 MEMORY PURGE 定义为尝试释放分配器保留的脏页；它不是删除 key，也不会替代数据建模优化。

redis-cli MEMORY PURGE
redis-cli INFO memory | egrep 'used_memory:|used_memory_rss:|allocator_active:|allocator_resident:|allocator_frag_ratio:'

前后对照至少看三件事：RSS 是否下降、allocator_resident 是否下降、业务延迟是否有异常。只看到比例变化而没有 RSS 或延迟证据，不足以说明处理有效。

上线后的结果怎么判：回收有效与无效是两种信号

有效的结果通常是 RSS 或分配器驻留内存出现可解释的下降，同时 used_memory 没有被意外改变，业务延迟保持在正常范围。这个结果可以记录为一次内存峰值后的回收。

无明显变化也不是失败。它可能说明活动页仍被其他对象使用，或当前分配器没有可归还的页。此时不要连续重复回收，回到采样趋势，检查批量任务、过期策略、客户端输出缓冲区和容器内存限制。

常见问题

allocator_frag_ratio 越高，Redis 就一定越危险吗？

不一定。它是需要结合趋势和 RSS 的信号；工作集稳定、RSS 有余量且延迟正常时，可以先观察。

used_memory 下降后，为什么 used_memory_rss 还不降？

释放的页可能仍由分配器保留，也可能处于峰值后的活动页状态。应同时看 allocator 字段和前后采样。

可以把 MEMORY PURGE 放进定时任务吗？

不建议脱离指标盲目定时执行。先验证实例的分配器、业务低峰和回收前后影响，再决定是否纳入受控运维流程。

把一次排查沉淀成可复用的检查单

下次遇到“数据没涨、RSS 却不降”，按这个顺序收口：保存同负载下的多次 INFO memory；区分工作集增长和分配器保留；核对分配器与回收能力；低峰执行一次受控验证；最后把 RSS、延迟和关键字段一起记录。这样得到的是可复查的内存证据，而不是一个脱离上下文的碎片率数字。