Redis MEMORY DOCTOR 的建议怎么解读

第一次看到 MEMORY DOCTOR 报“高内存碎片”时，我差点把处理动作直接等同于重启。后来把同一时刻的 INFO memory 展开，才发现实例刚经历过一次明显的内存峰值：当前数据已经回落，但分配器还保留着曾经向操作系统申请的页。这个经历让我形成了一个更稳妥的读法：先把 MEMORY DOCTOR 当成问题分类器，再用比率、绝对字节数和峰值上下文确认，它不是最终裁决。

官方文档：https://redis.io/docs/latest/commands/memory-doctor/

MEMORY DOCTOR 从 Redis Open Source 4.0.0 起可用，命令本身复杂度为 O(1)，返回人类可读的内存问题报告和建议。它很适合做排障入口，但内置的是一组启发式条件：实例太小时可能直接说明样本不足；某项比率越过阈值，也通常还要同时满足绝对字节数条件。因此，“没有发现问题”不等于没有容量风险，“发现碎片”也不等于必须重启。

MEMORY DOCTOR 先看结论再看证据

执行时建议一次收集三类信息，而不是只保存诊断文字：

# 获取启发式诊断文字
redis-cli MEMORY DOCTOR

# 读取核心内存指标，重点对比峰值、RSS、分配器和碎片字节数
redis-cli INFO memory

# 获取更细的内存开销拆分
redis-cli MEMORY STATS

这三条命令分别回答不同问题：

• MEMORY DOCTOR 回答“Redis 认为哪一类现象值得关注”。
• INFO memory 回答“关键比率、字节数和峰值分别是多少”。
• MEMORY STATS 回答“内存大致花在键值、数据结构、客户端、复制或其他开销的哪一部分”。

解读顺序最好是“建议类别 → 对应指标 → 绝对规模 → 业务影响”。例如，诊断提到分配器 RSS 开销时，不应只看 used_memory_rss 大不大，而要进一步确认 allocator_rss_ratio 和相关字节数；诊断提到客户端缓冲时，则要转向连接数量、输出缓冲和慢消费者，而不是继续调碎片参数。

为什么只看 mem_fragmentation_ratio 容易误判

mem_fragmentation_ratio 是 used_memory_rss / used_memory。它把进程驻留内存与 Redis 统计的已用内存放在一起比较，里面既可能有分配器外部碎片，也可能有分配器尚未归还的页、线程栈、共享库、复制或其他进程级开销。它不是“纯碎片率”。

旧的排障习惯经常只盯这个比率：大于某个数字就认定碎片严重，小于某个数字就认为安全。这个判断至少会漏掉三个上下文。

峰值会留下记忆

如果 used_memory_peak 曾经远高于当前 used_memory，键过期或业务回落后，Redis 已用内存会下降，但分配器不一定立刻把所有空闲页归还给操作系统。RSS 暂时保持较高会推高总碎片率。只要后续增长可以复用这些页，这种现象不一定意味着持续泄漏。

比率必须和字节数一起看

小实例里几十兆的固定开销就可能产生很高比率，但实际回收收益有限；大实例里比率变化不大，绝对差值却可能是数十 GB。官方指标同时提供 mem_fragmentation_bytes、allocator_frag_bytes 等绝对量，就是为了避免只看比例。

RSS 高不等于数据集大

used_memory 关注 Redis 分配的内存，used_memory_rss 关注操作系统看到的驻留页。两者差异可能来自多个层次。要判断真正的分配器外部碎片，应优先看 allocator_frag_ratio = allocator_active / allocator_allocated；要判断分配器保留了多少可能归还的页，应看 allocator_rss_ratio = allocator_resident / allocator_active。

把建议拆成峰值、分配器、进程和连接四层

Redis 源码中的 MEMORY DOCTOR 会检查多类症状，包括明显的历史峰值、总碎片、分配器碎片、分配器 RSS、非分配器进程 RSS，以及客户端或副本缓冲。把它们都叫作“碎片”会丢失处置方向。我通常把建议拆成下面四层：

1. 峰值记忆：当前分配量相对历史峰值已经明显回落，高 RSS 可能只是峰值后的保留页。
2. 分配器层：allocator_frag_ratio 高更接近外部碎片；allocator_rss_ratio 高则更接近分配器保留了可尝试归还的页。
3. 进程层：总 RSS 与分配器 RSS 之间仍有显著差异时，问题可能来自分配器之外，不能靠碎片整理一概解决。
4. 连接层：普通客户端或副本缓冲过大，说明慢消费者、网络、复制积压或连接管理需要调查。

还有两种提示也容易被忽略。第一，实例总分配量过小时，医生会认为诊断意义有限；这不是健康证明，只是样本没有达到启发式分析的规模。第二，缓存脚本数量过多会形成独立内存压力，应检查脚本使用方式与版本提供的缓存管理能力，而不是调 jemalloc。

用 INFO memory 与 MEMORY STATS 交叉确认

诊断文字和指标的对应关系可以按下表理解。字段名称以当前 Redis 官方 INFO memory 文档为准，不同版本可能缺少个别指标，生产脚本应先确认版本。

一次快照只能说明当下状态。更可靠的做法是在业务低谷、正常负载和峰值后分别采集同一组字段，画出 used_memory、used_memory_rss、峰值、分配器 active/resident 以及碎片字节数的趋势。如果 RSS 持续上升而数据量、连接数和峰值都无法解释，才需要把调查扩大到版本缺陷、模块、Lua/Functions、客户端行为或系统级内存。

不同建议对应什么动作

分配器 RSS 较高：先评估 MEMORY PURGE

MEMORY PURGE 会请求内存分配器释放脏页。它适合“分配器 resident 明显高于 active”的方向，不保证每次都能立即降低 RSS，也不负责修复客户端缓冲或非分配器内存。

# 仅在诊断指向 allocator RSS overhead 时尝试回收空闲页
redis-cli MEMORY PURGE

# 变更后继续读取同一组指标，观察趋势而不是只看一次结果
redis-cli INFO memory

执行前要确认实例使用的分配器和版本支持情况，并在低风险窗口观察延迟与 CPU。若页仍被使用、分配器无法回收或操作系统行为不同，命令可能没有明显效果。

分配器外部碎片：再考虑 activedefrag

主动碎片整理针对的是 jemalloc 管理的外部碎片，不是所有 RSS 偏高。启用前先确认当前配置和指标确实指向 allocator_frag_ratio/allocator_frag_bytes，再结合 CPU 余量、延迟目标和版本文档制定参数。不要因为总碎片率高就直接在线打开。

# 先读取是否已启用主动碎片整理
redis-cli CONFIG GET activedefrag

# 同时读取内存指标，确认问题确实位于分配器碎片层
redis-cli INFO memory

主动整理会消耗 CPU。生产环境应通过配置文件和变更流程管理，并设置停止条件；如果延迟恶化或碎片字节没有改善，应撤销变更并重新判断问题层次。

客户端或副本缓冲：找慢消费者和复制链路

当建议指向客户端缓冲时，动作是识别连接类型、输出缓冲、订阅者、阻塞命令和消费速度。副本缓冲偏大时，应检查复制延迟、断线重连、全量同步频率、网络吞吐以及复制积压配置。限制缓冲只能降低失控风险，不能替代对慢消费者和网络瓶颈的修复。

历史峰值：容量规划通常比立即重启更重要

如果高 RSS 能被过去峰值解释，而且实例会再次增长到同一水位，保留页可能很快被复用。此时重启只是把 RSS 数字暂时压低，却带来恢复、故障转移和缓存重建风险。更值得做的是确认节点、容器和宿主机是否按峰值而非当前均值预留内存，并验证 maxmemory 与淘汰策略。

上线处理与复查

我会把一次内存处理压缩成六个检查点：

1. 记录 Redis 版本、运行时、业务阶段和最近峰值时间。
2. 同时保存 MEMORY DOCTOR、INFO memory 与 MEMORY STATS，而不是只截取建议文字。
3. 先用绝对字节数判断收益，再用比率判断结构，避免小实例高比率误导。
4. 一次只改一个变量，例如先尝试 purge，或单独调整碎片整理策略。
5. 同步观察 CPU、命令延迟、驱逐、复制和业务错误，内存下降不能以稳定性为代价。
6. 在一个完整业务周期后复查趋势；只比较变更前后两个瞬时点很容易受流量影响。

如果需要重启，应把它当作最后的受控恢复动作，而不是 MEMORY DOCTOR 的默认答案。先确认高可用、持久化、恢复时间、复制健康和回滚路径；否则为了释放一部分 RSS，可能换来更大的业务风险。

常见问题

MEMORY DOCTOR 返回没有问题，就代表不会 OOM 吗？

不代表。它只检查有限的启发式症状，不负责预测业务增长、容器限制、宿主机竞争或所有模块内存。容量告警仍要基于峰值、增长速度、maxmemory、RSS 和系统可用内存。

mem_fragmentation_ratio 高于 1 就一定异常吗？

不是。进程运行需要分配器和非数据内存，峰值后也可能保留页。应同时看 mem_fragmentation_bytes、历史峰值、分配器指标以及持续时间。

执行 MEMORY PURGE 会阻塞吗？

它是管理命令，实际成本与分配器、内存规模和可回收页有关。不要把命令复杂度标签等同于生产零影响；应在受控窗口执行并监控延迟，而且它可能无法回收正在使用或不满足释放条件的页。

activedefrag 和 MEMORY PURGE 可以互相替代吗？

不能。主动碎片整理着眼于重新组织分配器中的对象以降低外部碎片，purge 着眼于请求分配器把空闲页归还给操作系统。一个对应 active/allocated，另一个更接近 resident/active，判断依据不同。

为什么重启后 RSS 下降，过一阵又回来了？

重启清空了分配器状态，但没有改变数据结构、流量峰值、客户端积压或容量上限。若根因仍在，实例会重新走到相似水位。重启后的短期下降只能证明内存可以被重建，不能证明问题已经修复。

最实用的结论是：MEMORY DOCTOR 告诉你先看哪里，INFO memory 告诉你现象有多大，MEMORY STATS 帮你判断内存花在哪里，时间趋势才决定是否真的需要动作。把建议放回峰值、分配器、进程和连接四个层次，通常就能避免“碎片率一高就重启”这类代价很大的误判。