instantaneous_ops_per_sec突然下跌通常不是负载降低，而是内存回收（淘汰或过期key清理）抢占主线程导致命令处理受阻；需结合evicted_keys/ expired_keys增速、used_memory_human接近maxmemory、redis-cli --stat中evicted与cmd列负相关等现象综合判断。
为什么instantaneous_ops_per_sec突然下跌，可能不是负载低而是内存在猛回收
当 instantaneous_ops_per_sec 持续低于日常均值（比如跌去 30% 以上），且没有明显业务流量下降时，大概率不是 Redis 变闲了，而是主线程正被内存淘汰（eviction）或过期 key 清理（active expiry）抢占。Redis 单线程模型下，这些后台动作和命令处理共享同一事件循环，一旦回收逻辑耗时变长，instantaneous_ops_per_sec 就会“被动压低”。
- 检查
INFO memory中evicted_keys和expired_keys的每秒增量：用脚本每 2 秒采一次差值，>500/sec 是强信号 - 同步看
used_memory_human是否长期 >95%maxmemory；若接近硬上限，淘汰已成常态 -
instantaneous_ops_per_sec下跌 +evicted_keys跳涨 +cmd列在redis-cli --stat中骤降，三者共现基本可锁定回收阻塞
用redis-cli --stat实时盯住回收与吞吐的此消彼长
redis-cli --stat 不显示耗时，但它的刷新节奏和字段跳变更贴近真实压力反馈——尤其适合快速定位“回收正在吃掉吞吐”的现场。
- 重点关注输出中的
evicted列：非零且频繁跳变（如 0→127→0→203），说明淘汰在持续发生 -
mem列逼近maxmemory时，若cmd列数值同步萎缩（比如从 8k → 2k），就是回收挤占命令处理的直接证据 - 不要依赖单次输出，要观察连续 5–10 秒的滚动变化；瞬时抖动无意义，持续性负相关才有诊断价值
INFO stats里的instantaneous_ops_per_sec不是平均值，是最近一秒的瞬时采样
instantaneous_ops_per_sec 是 Redis 内部用环形缓冲区（默认 16 个 slot）滚动记录每秒命令数后取的最新值，它不累计、不平滑、不加权——本质是“最后一秒发生了多少事”。这决定了它对短时回收风暴极其敏感。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 它和
total_commands_processed完全不同：total_commands_processed是单调递增计数器，适合算长期 QPS；而instantaneous_ops_per_sec是诊断毛刺的第一反应指标 - 生产环境告警阈值不能定死：若日常峰值是 15k，可设“连续 3 秒
- 它受客户端 pipeline 批量大小影响显著：同样吞吐下，大 pipeline 会让该值虚高，小请求则拉低——需结合
instantaneous_input_kbps综合判断
真正要盯的不是 instant_ops_per_sec 数值本身，而是它和 evicted_keys 的协方差
单独看 instantaneous_ops_per_sec 容易误判。必须把它和 evicted_keys 增速放在同一时间尺度上对齐分析，才能区分是“真低负载”还是“假空闲”。
- 写个极简轮询脚本：
redis-cli INFO memory | grep -E "(used_memory_human|maxmemory|evicted_keys)"和redis-cli INFO stats | grep instantaneous_ops_per_sec同步抓取，间隔 1 秒 - 若
evicted_keys每秒增长 ≥300，而instantaneous_ops_per_sec同步跌超 40%，基本可确认淘汰已影响服务能力 - 此时再查
latency_graph中是否有eviction类型延迟尖峰（需提前运行redis-cli --latency-history -i 1）——这是最终确认依据
内存回收不产生日志，也不报错，但它会让 instantaneous_ops_per_sec 变成一个“沉默的受害者”。盯住它和 evicted_keys 的联动关系，比调高 active-expire-effort 或改淘汰策略更早发现问题根源。
