必须组合evicted_keys、expired_keys和延迟信号才能确认是否在“边扛压边淘汰”；仅看info memory不够，需监控used_memory_human与maxmemory比值、evicted_keys每秒增量、expired_keys增速，并结合--stat卡顿现象及latency_graph中eviction延迟尖峰综合判断。
淘汰已发生，光看 INFO memory 不够；必须组合 evicted_keys、expired_keys 和延迟信号才能确认是否在“边扛压边淘汰”。
怎么从 INFO memory 判断淘汰正在高频执行
直接运行 redis-cli INFO memory，重点盯三个字段：
-
used_memory_human与maxmemory的比值 —— 长期 >95% 就不是“偶尔触发”，而是常态压力 -
evicted_keys是累计总数，不能单看；写个脚本每 2 秒执行一次INFO memory，取差值：如果每秒增量 >500，说明主线程正频繁腾内存 -
expired_keys增速快但evicted_keys几乎不动？大概率是淘汰策略配成了noeviction，而非没努力删
为什么 redis-cli --stat 看起来“卡顿”可能就是淘汰在抢 CPU
redis-cli --stat 每秒刷新一次，但它显示的 evicted 列跳变 + mem 列逼近上限 + cmd 列数值骤降，这三者同步出现，基本等于淘汰正在阻塞主线程。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 这不是瞬时值，而是 Redis 每 100ms 执行一次
serverCron()后聚合的结果 - 如果
cmd值持续掉到平时的 60% 以下，同时evicted每秒涨几十上百，就别等告警了——现在就得查 - 注意：
--stat不显示耗时，但它暴露的是淘汰对命令吞吐的“可见影响”
latency_graph 中 eviction 延迟尖峰才是真实耗时证据
Redis 不暴露单次淘汰耗时，但会把淘汰动作归类为 eviction 类型延迟事件：
- 提前运行
redis-cli --latency-history -i 1持续采样（至少 5 分钟） - 再执行
redis-cli --latency-dist或看INFO latency，找eviction行的 P99 值是否突增（比如从 0.2ms 跳到 8ms） - 一旦出现 >5ms 的
eviction尖峰，且和evicted_keys增速时间吻合，就能断定淘汰逻辑正在拖慢响应 - 这种延迟不是“删一个 key 花多久”，而是整个淘汰循环挤占了命令处理时间片
CONFIG GET active-expire-effort 改高反而可能让问题更糟
这个参数控制定期删除过期 key 的“努力程度”，默认是 1，设成 10 并不等于“删得更快”，而是让 Redis 在每次 serverCron() 里花更长时间抽样、判断、删除：
- 它不改变单次抽查 key 数量（固定 20 个），只决定“要不要继续下一轮”
- 小内存实例或高并发场景下，设为 10 容易引发
latency spikes，尤其当mem_fragmentation_ratio > 1.5时，释放的内存 OS 不回收，反而加剧后续淘汰压力 - 真正该调的不是它，而是先确认
maxmemory是否合理、淘汰策略是否匹配业务（比如写多读少别用volatile-lru）
淘汰监控最难的点不在数据采集，而在解读信号之间的矛盾——比如 expired_keys 很高但 evicted_keys 几乎为 0，或者 used_memory_human 没超限却频繁触发淘汰。这时候得回头检查 CONFIG GET maxmemory-policy 和实际 key 的 EXPIRE 分布，而不是急着调参。
