碎片该怎么处理
内存碎片会让「操作系统看到的进程内存」明显大于「Redis 自己记录的分配量」。INFO memory 里的 mem_fragmentation_ratio 就是这两个数的比值：大于 1 说明有多余碎片，小于 1 往往意味着内存被换出到 swap。处理路径一般是先确认规模，再决定开启在线整理还是安排重启。
基本信息
| 观察指标 | mem_fragmentation_ratio = used_memory_rss / used_memory |
|---|---|
| 在线整理 | activedefrag 及相关阈值参数 |
| 诊断建议 | MEMORY DOCTOR 会给出判断 |
| 兜底手段 | 低峰重启，重启前确认持久化状态可用 |
典型使用场景
- 比例长期在 1.5 以上，评估是否开启在线碎片整理
- 键量大且频繁删除重建的业务，碎片增长明显更快
- 容器内存配额紧张时，碎片会直接挤占可用额度
- 调整过最大内存或做过大批量删除之后，复查碎片情况
- 决定重启前，先判断回收收益是否值得一次停写窗口
观测与在线整理
观测与在线整理
# 看分配量与 RSS 的差距，以及碎片比例
redis-cli INFO memory | grep -E 'used_memory|used_memory_rss|mem_fragmentation_ratio'
# 让实例自己给诊断（碎片、swap、内存构成都会提示）
redis-cli MEMORY DOCTOR
# 开启在线整理并控制节奏
redis-cli CONFIG SET activedefrag yes
redis-cli CONFIG SET active-defrag-ignore-bytes 100mb # 碎片小于这个量就不折腾
redis-cli CONFIG SET active-defrag-threshold-lower 10 # 碎片率达到 10% 开始整理
redis-cli CONFIG SET active-defrag-cycle-max 25 # 每轮最多占用四分之一 CPU 时间指标读法
| 指标 | 含义 | 怎么看 |
|---|---|---|
| used_memory | Redis 记录的分配量 | 反映数据集规模 |
| used_memory_rss | 操作系统看到的进程常驻内存 | 与分配量的差额就是碎片与开销 |
| mem_fragmentation_ratio | 两者比值 | 大于 1.5 偏高，小于 1 说明发生了 swap |
| allocator_frag_ratio | 分配器层面的碎片率 | 反映分配器管理效率 |
| active_defrag_running | 当前是否正在整理 | 为 1 表示整理正在进行 |
在线整理只回收分配器层面的碎片，大键与海量小键带来的结构开销不会因此消失；比例长期偏高时，还要回到数据模型上找原因。
重启是最彻底的回收方式，但代价是一次停写窗口；执行前确认持久化文件可用、主从关系清晰，并选在业务低峰，避免重启后加载失败导致更大的中断。