延迟监控怎么用
延迟监控记录事件时间线，是排查周期性卡顿的关键工具。但它默认是关闭的：必须先设置 latency-monitor-threshold（单位毫秒），Redis 才会记录耗时超过阈值的事件。之后用 LATENCY LATEST 看各类事件最近一次与最差一次的延迟，用 LATENCY HISTORY 看某个事件的历史曲线，用 LATENCY DOCTOR 拿到文字化的诊断建议。
基本信息
| 开启前提 | latency-monitor-threshold 设为大于 0 的毫秒数 |
|---|---|
| LATENCY LATEST | 各事件最近一次与最大一次延迟 |
| LATENCY HISTORY | 指定事件的历史延迟序列 |
| LATENCY DOCTOR | 汇总成可读的诊断结论 |
| LATENCY RESET | 清空历史记录，便于重新观察 |
典型使用场景
- 排查每天固定时间点出现的延迟毛刺
- 确认卡顿来自 fork、键过期还是命令本身
- 交接前把采集打开，避免事后没有数据可查
- 评估快照或重写期间的延迟影响
- 对比优化前后的延迟曲线变化
开启与分析
开启与分析
CONFIG SET latency-monitor-threshold 100 # 记录超过 100 毫秒的事件
LATENCY LATEST # 各事件最新一次与最大一次延迟
LATENCY HISTORY fork
LATENCY HISTORY command
LATENCY HISTORY expire
LATENCY DOCTOR # 汇总成可读的诊断结论
LATENCY RESET # 清空历史记录命令与用途
| 命令 | 返回内容 | 用途 |
|---|---|---|
| latency-monitor-threshold | 采集阈值，单位毫秒 | 设为 0 表示关闭采集 |
| LATENCY LATEST | 事件名、时间戳、最近与最大延迟 | 快速判断有没有异常 |
| LATENCY HISTORY | 指定事件的延迟序列 | 判断是否为周期性规律 |
| LATENCY DOCTOR | 文字结论 | 为排查指明方向 |
| LATENCY RESET | 清空历史 | 调整阈值后重新开始观察 |
延迟监控的开销很低，生产环境建议常开，阈值设 100 毫秒即可；真出问题时手里有历史曲线，比现场抓 MONITOR 靠谱得多。
没有设置阈值就直接查 LATENCY LATEST，结果永远是空列表，很容易让人误以为实例没有卡顿。排查之前先确认采集是否已经打开。
只看单次延迟意义有限：结合 HISTORY 的趋势才能判断是偶发抖动还是周期性规律，后者通常指向快照、重写或大量键集中过期。再配合持久化状态与慢日志交叉比对，多数情况半小时内就能定位到具体环节。