内存与延迟的联合分析
内存压力和延迟尖峰经常同时出现，因为它们的成因往往是同一件事：达到水位触发淘汰、过期键集中清理、fork 期间写时复制、碎片整理、大键删除。把这些信号放在同一条时间轴上对齐，能找到只有单看一侧永远发现不了的关联，再据此验证因果。
基本信息
| 内存侧信号 | 已用内存、淘汰计数、过期计数、碎片率 |
|---|---|
| 延迟侧信号 | 延迟事件的最近与历史记录、慢查询日志、客户端分位延迟 |
| 前提 | 延迟监控阈值已开启，默认 0 表示关闭 |
| 方法 | 统一时间轴，找同期事件 |
| 产出 | 因果假设加单变量验证 |
| 注意 | 采集缺口与时钟偏差要标注 |
典型使用场景
- 内存告警同时延迟抖动：判断是淘汰、过期风暴还是 fork 造成的
- 事件复盘：把发布、批任务、切换等变更与指标拐点对齐
- 优化验收：改动前后用同一时间轴对比，确认收益真实存在
- 容量决策：把峰值余量与恢复时间一起看，决定是否扩容
- 监控建设：统一采集间隔与时间源，为后续关联分析打基础
最小示例
最小示例
redis-cli CONFIG GET latency-monitor-threshold # 0 表示关闭延迟监控
redis-cli LATENCY LATEST # 最近的事件与最大延迟
redis-cli LATENCY HISTORY fork # 某个事件的历史记录
redis-cli LATENCY DOCTOR # Redis 给出的成因分析
redis-cli INFO stats | grep -E 'evicted_keys|expired_keys' # 淘汰与过期计数
redis-cli INFO memory | grep -E 'mem_fragmentation_ratio|active_defrag_running|lazyfree_pending_objects'信号组合
| 同期现象 | 可能因果 | 验证方式 |
|---|---|---|
| 淘汰计数上涨加延迟尖峰 | 达到水位触发淘汰 | 提高水位或扩容后复测 |
| 过期计数尖峰加周期性延迟 | 过期键集中清理 | 打散 TTL，避免同一时刻集中到期 |
| 子进程 CPU 上涨加内存台阶 | fork 与写时复制 | 对照重写与保存的时间点 |
| 碎片率上升加 CPU 上升 | 碎片整理在持续执行 | 核对碎片整理相关状态与开关 |
| 客户端缓冲上涨而数据集不变 | 连接或输出缓冲膨胀 | 查 CLIENT LIST 的输出缓冲与连接数 |
两条曲线对齐的瞬间就是最有价值的证据窗口：先建立假设，再只改一个变量去验证，同时动多项会让结论无法归因。
分析前先统一时间轴：采集间隔、时钟同步与监控缺口都要标注，否则看似相关的两个拐点其实错位。