内存告警五步法
收到内存告警时的处置顺序应当固定：先看 used_memory 与 maxmemory 的关系以及淘汰计数，再找大 key 与过期堆积，然后看碎片率与 RSS 是否背离，接着做短期止损（清理与调策略），最后回到长期根治（拆分、扩容、改设计）。顺序错了容易做过度的动作，比如先扩容却没发现是碎片问题。
基本信息
| 关键命令 | INFO memory / INFO stats / INFO keyspace / INFO clients |
|---|---|
| 淘汰策略 | maxmemory-policy，noeviction 下写命令直接报错 |
| 碎片指标 | mem_fragmentation_ratio，配合 RSS 与 used_memory 对比 |
| 短期止损 | 低峰清理大 key、调整淘汰策略、临时扩容 |
| 长期根治 | 拆分实例、扩容、重新设计键结构与 TTL |
典型使用场景
- 内存告警后需要快速判断是容量不足还是碎片问题
- 写命令开始返回 OOM 类错误，业务已经受影响
- 大促或活动前的容量复核与压测结论核对
- 清理大 key 后内存没有明显下降，怀疑碎片或缓冲区
- 主从复制缓冲区或客户端输出缓冲区异常吃内存
应急检查
应急检查
redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human|maxmemory_policy|mem_fragmentation_ratio"
redis-cli INFO stats | grep -E "evicted_keys|expired_keys"
redis-cli INFO keyspace # 各库的 keys 与 expires 数量
redis-cli INFO clients | grep -E "connected_clients|client_recent_max_output_buffer"
redis-cli --bigkeys -i 0.1 # 低峰或副本上执行
redis-cli MEMORY DOCTOR # 官方一句话体检
redis-cli MEMORY PURGE # 尝试归还碎片，效果通常有限判断项与结论方向
| 观察项 | 看什么 | 结论方向 |
|---|---|---|
| used 接近 maxmemory 且淘汰增长 | 容量水位与淘汰计数 | 容量不足，扩容或调整淘汰策略 |
| fragmentation_ratio 大于 1.5 | 碎片率偏高 | 考虑重启或迁移实例回收碎片 |
| RSS 高而 used 低 | 内存被分配器持有 | 多为碎片，而非数据真的变多 |
| noeviction 下报 OOM | 写命令被拒绝 | 先调策略或扩容，保住业务写入 |
| 输出或复制缓冲区偏大 | 慢客户端与从库积压 | 排查慢消费者与复制延迟 |
调大 maxmemory 前先确认物理内存余量：把问题从「Redis 报错」变成「操作系统 OOM Killer 杀进程」更糟，同机其它服务与从库的内存也要一并核算。
只清大 key 不改设计，两三周后同样的告警还会再来一次。清理只是止损，真正的解法是拆键、补 TTL、把单实例规模控制在可维护范围内。
内存问题不全是数据增长：客户端输出缓冲区、复制缓冲区、AOF 缓冲区都会在没有新增数据的情况下吃掉内存，排查时按这几项逐条排除。