redis不直接暴露单次淘汰耗时，需结合info memory中evicted_keys增长速率（>500/sec为高频信号）、used_memory_human与maxmemory对比（>95%即常态淘汰），以及latency_graph中eviction延迟尖峰综合判断。
如何用 INFO memory 实时观察淘汰耗时
Redis 本身不直接暴露“单次淘汰耗时”这个指标，但会统计淘汰行为的总体开销和频率——关键看 evicted_keys 和 expired_keys 的增长速度，再结合 used_memory_peak_human 和 mem_allocator 判断是否在频繁触发回收。
真正反映“执行耗时压力”的是 total_commands_processed 与 instantaneous_ops_per_sec 的异常下跌，以及 latency_graph 中出现的 eviction 类型延迟尖峰（需提前运行 redis-cli --latency-history -i 1 持续采样）。
-
INFO memory中的maxmemory和used_memory_human必须持续对比，一旦used_memory_human长期 > 95%maxmemory，淘汰已成常态，此时evicted_keys每秒递增就是最直接的耗时信号 - 不要只盯
evicted_keys绝对值——它只累计总数；要写个简单脚本每 2 秒抓一次差值，> 500/sec 就说明淘汰正在高频发生，主线程已在争抢 CPU 时间片 - 如果
mem_allocator是jemalloc，还要看used_memory_rss_human是否远大于used_memory_human，这表示内存碎片严重，淘汰后释放的内存没被 OS 回收，反而加剧后续淘汰压力
CONFIG GET active-expire-effort 怎么影响实际耗时
这个参数控制定期删除的“努力程度”，默认是 1，取值范围 1–10。它不改变单次抽样 key 数（固定 20 个），而是决定：当过期 key 比例 >10% 且未超时（FAST 模式 1ms / SLOW 模式 25ms），是否继续下一轮抽样。
- 设为
1（默认）：过期 key 比例 ≤10% 就停，适合读多写少、过期 key 分布均匀的场景 - 设为
10：只要没超时上限，就反复抽样直到比例 ≤10% 或时间到——这会显著拉高单次serverCron()耗时，可能挤占命令处理时间，尤其在小内存实例上容易引发latency spikes - 生产环境不建议调高；若发现
expired_keys增长快但evicted_keys几乎不动，说明淘汰策略（如noeviction）被误配，而不是active-expire-effort不够
为什么 redis-cli --stat 看不到淘汰耗时，但能帮你定位问题
redis-cli --stat 不显示耗时，但它实时刷新的字段里藏着线索：evicted 列跳变、maxmemory 列突然变红、mem 列逼近上限并伴随 cmd 列数值骤降——这三者同时出现，基本可断定淘汰正在阻塞主线程。
- 注意
--stat默认每秒刷新一次，但 Redis 的淘汰检查是每 100ms 一次（由hz控制），所以你看到的其实是“聚合后的压力表现”，不是瞬时值 - 如果
evicted列稳定在 0，但mem持续上涨，说明过期 key 还没被定期删除扫到，或惰性删除也没被触发——这时要查客户端是否真在读那些 key，还是数据根本没人碰 - 搭配
redis-cli --bigkeys一起跑，能快速识别出是不是某个超大 hash/set 占着内存不放，导致淘汰机制“挑来挑去都挑不到合适的小 key”而反复失败
用 MEMORY PURGE 和 MEMORY MALLOC-STATS 辅助判断真实回收效率
淘汰 key 只是逻辑删除，内存是否真正归还给 OS，取决于分配器行为。MEMORY PURGE（仅 jemalloc 支持）可强制归还脏页，而 MEMORY MALLOC-STATS 能看出当前碎片率。
- 执行
MEMORY PURGE后，立刻INFO memory对比used_memory_rss_human是否下降——如果没降，说明内存还在 Redis 内部池子里没还，淘汰产生的“空闲”其实没缓解压力 -
MEMORY MALLOC-STATS输出中关注active:allocated比值，> 1.5 就说明碎片严重；此时即使淘汰了大量 key，RSS 也难下降，监控看到的“耗时”其实是 malloc 层在反复整理内存块 - 别在高峰期执行
MEMORY PURGE，它会短暂阻塞所有命令；建议配合CONFIG SET maxmemory-policy allkeys-lru一起用，避免因策略不匹配导致 purge 后立即又触发淘汰
淘汰耗时从来不是孤立指标——它永远缠绕在过期策略、淘汰策略、内存分配器、客户端访问模式之间。盯着一个数字没用，得把 INFO memory、INFO stats、MEMORY STATS 和 redis-cli --latency 的输出放在同一时间轴上对齐看。
