用redis-cli --stat实时看evicted_keys增速，执行redis-cli --stat -i 2，每2秒刷新一行，括号内数值（如+57）即为过去2秒淘汰key数；连续多行出现+100、+200表明内存持续承压。

怎么用 redis-cli --stat 实时看 evicted_keys 增速

redis-cli --stat 是最轻量、最贴近线上实况的监控方式，它每秒刷新一行，其中最后一列就是 evicted_keys 的增量（不是累计值）。关键不是看绝对数字，而是括号里的变化量。

• 执行 redis-cli --stat -i 2，每 2 秒刷新一次，输出类似：8890 131.97M 47 0 1705992954 (+57) 2595，括号中 +57 表示过去 2 秒淘汰了 57 个 key
• 连续几行都出现 +100、+200，说明内存压力持续存在，不是偶发抖动
• 如果 evicted 列长期为 0，但 mem 列已逼近 maxmemory，大概率是策略配成了 noeviction，此时写命令会直接报错 (error) OOM command not allowed when used memory > 'maxmemory'

为什么 INFO memory 里的 evicted_keys 不够用

evicted_keys 在 INFO memory 中是累计值，只告诉你“总共淘汰过多少次”，不反映节奏。单次查询无法判断是突发尖峰还是缓慢爬升，更看不出是否正在抢主线程 CPU。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 运行 redis-cli INFO memory | grep evicted_keys 得到 evicted_keys:12489，这个数本身没意义
• 真正要关注的是速率：写个简单脚本每 2 秒抓一次 evicted_keys，取差值除以时间间隔；> 500/sec 就说明淘汰逻辑已在高频执行
• 别漏掉对照项：expired_keys（INFO stats 里查）增速快但 evicted_keys 几乎不动？那淘汰根本没生效，策略可能误配

RedisInsight 里怎么避免把累计值当实时压力

RedisInsight 默认图表展示的是 evicted_keys 累计曲线，平缓上升看起来很安全——但这恰恰是最大陷阱。必须切换到速率模式才能识别真实负载。

• 进入 Memory 标签页后，找到 evicted_keys 图表，点击右上角 Rate 按钮（不是 “Per Second” 或 “Derivative” 其他选项）
• 叠加观察：used_memory_human 曲线是否长期 > 95% maxmemory，且 evicted_keys Rate 曲线是否稳定在 > 500/sec
• ⚠️ 容易踩的坑：evicted_keys 在 RedisInsight 里默认不带时间对齐，导出 CSV 后需用脚本算 delta；否则你看到的只是“总量在变”，不是“此刻有多忙”

淘汰真正在拖慢响应？得盯 latency_graph 里的 eviction 尖峰

Redis 不暴露单次淘汰耗时，但会把整个淘汰循环归类为 eviction 类型延迟事件。这才是确认“淘汰是否已成性能瓶颈”的唯一硬指标。

• 提前运行：redis-cli --latency-history -i 1 | grep "eviction" > /tmp/eviction-latency.log &，持续采样至少 5 分钟
• 执行 redis-cli --latency-dist，检查 eviction 行的 P99 是否突增（比如从 0.2ms 跳到 8ms）
• 若 eviction 延迟尖峰和 evicted_keys 增速高峰时间吻合，且 instantaneous_ops_per_sec 同步下跌超 40%，基本可断定淘汰正在挤占命令处理时间片

实际排查时，最容易被忽略的是：evicted_keys 增速高，未必是数据太多，也可能是 mem_fragmentation_ratio > 1.5 导致 OS 无法回收内存，或者大 key 占着大量空间却难以被采样淘汰。先查碎片率、再扫大 key，比盲目调策略更有效。