内存碎片从哪来
碎片指进程 RSS 明显大于 used_memory：频繁增删键、值大小不一致会让分配器留下无法复用的空洞。Redis 4.0 起支持 activedefrag 在线整理，用 ignore-bytes 设启动门槛、threshold-lower 与 threshold-upper 控制整理力度，cycle 系列参数则约束 CPU 占用节奏，避免整理本身影响业务。
基本信息
| 适用 | Redis 4.0 及以上支持 activedefrag |
|---|---|
| 启动门槛 | active-defrag-ignore-bytes 与 threshold-lower |
| 力度控制 | threshold-upper 触发全力整理 |
| CPU 控制 | active-defrag-cycle-* 系列参数控制占空比 |
| 关键指标 | mem_fragmentation_ratio 与 allocator_frag_ratio |
启用与观察
启用与观察
CONFIG SET activedefrag yes # 开在线碎片整理
CONFIG SET active-defrag-ignore-bytes 100mb # 碎片小于该值不整理
CONFIG SET active-defrag-threshold-lower 10 # 碎片率超过 10% 才开始
CONFIG SET active-defrag-threshold-upper 100 # 达到 100% 全力整理
INFO memory | grep -E 'mem_fragmentation_ratio|allocator_frag_ratio|active_defrag_running'
INFO memory | grep -E 'used_memory_human|used_memory_rss_human' # 对比逻辑内存与物理内存参数与指标读法
| 项 | 含义 | 怎么判断 |
|---|---|---|
| mem_fragmentation_ratio | RSS / used_memory | 明显大于 1 说明物理占用偏高 |
| allocator_frag_ratio | 分配器层面碎片率 | 更直接反映空洞程度 |
| ignore-bytes | 碎片总量低于该值不整理 | 避免小碎片反复触发 |
| threshold-lower | 碎片率下限 | 超过才启动整理 |
| threshold-upper | 碎片率上限 | 达到后全力整理，CPU 占用更高 |
| active_defrag_running | 是否正在整理 | 为 1 时观察 CPU 与延迟 |
典型使用场景
- RSS 持续高于 used_memory，评估是否需要在线整理
- 键生命周期混乱导致的碎片治理，先整理再改设计
- 容量规划：确认真实可用内存到底有多少
- 重启窗口评估：不支持的版本只能靠重启释放碎片
- 参数调优：控制整理对 CPU 与延迟的影响
碎片的主要成因是大量删除键与分配器尺寸类不匹配，在线整理只是治标；管理键生命周期（TTL、分桶、统一值尺寸）才是治本。
全力整理期间 CPU 会出现抖动，生产环境要结合 cycle 参数与业务峰值安排，避免在流量高峰开启高强度整理。
整理之外的治本动作
- 整理期间盯住延迟指标，一旦出现毛刺就调低 cycle 强度或暂停
- 分配器无法回收的碎片需要通过重启实例或迁移数据才能真正释放
- 统一 value 尺寸并给键设置 TTL，能从源头减少后续碎片产生