redisinsight中需结合memory页的used_memory_human曲线（>95% maxmemory）与evicted_keys速率曲线（>500/sec）叠加判断高频淘汰；默认evicted_keys为累计值，须点击rate按钮转换为每秒增量才可识别压力节奏。
RedisInsight里怎么看内存淘汰是否在高频发生
RedisInsight本身不直接显示“单次淘汰耗时”，但能通过evicted_keys的累计增长趋势+内存水位线交叉判断淘汰是否已成常态。关键不是看绝对值，而是单位时间内的增幅。
进入对应实例的 Memory 标签页后，重点关注两个叠加图：
-
used_memory_human曲线（实线）——实时内存占用 -
evicted_keys的导数曲线（即每秒新增淘汰数，需开启“Rate”模式或手动计算差值）
当used_memory_human长期贴近你配置的maxmemory（比如 >95%），同时evicted_keys每秒增量持续 > 500，基本可断定淘汰逻辑正在高频抢占主线程CPU时间片。
⚠️ 容易踩的坑：evicted_keys在RedisInsight图表中默认是累计值，不带速率转换；必须点击图右上角的 Rate 按钮（或导出CSV用脚本算 delta），否则看不出压力节奏。
为什么在RedisInsight里看不到eviction延迟尖峰
因为redis-cli --latency-history -i 1采集的eviction类型延迟，不会自动上报到RedisInsight的监控指标流里。RedisInsight的 latency 图表只展示它自己采集的command和fast-command延迟，不包含 serverCron 中淘汰阶段的细分耗时。
要补上这块缺口，得额外做两件事：
- 在Redis服务器上后台运行：
redis-cli --latency-history -i 1 | grep "eviction" > /tmp/eviction-latency.log & - 把该日志按时间戳对齐到RedisInsight的
used_memory_human曲线，就能定位哪次内存冲高触发了真实延迟尖峰
注意：--latency-history采样本身有开销，生产环境建议仅在问题复现期临时开启，采样间隔不低于1秒。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
CONFIG GET active-expire-effort 在RedisInsight里怎么调
RedisInsight不提供直接修改active-expire-effort的图形入口，但可以通过内置CLI终端执行：
CONFIG SET active-expire-effort 1
这个参数影响的是过期key清理的“努力程度”，不是淘汰策略本身。设为10并不会让noeviction变allkeys-lru，它只决定Redis在每次serverCron周期里花多少时间扫描过期key。
实际效果差异明显：
-
active-expire-effort 1：过期key比例 ≤10% 就停，适合写少读多、key生命周期均匀的场景 -
active-expire-effort 10：只要没超25ms时限就反复扫，容易在小内存实例上引发latency spikes，且对evicted_keys无直接影响
别误以为调高它就能缓解淘汰压力——真正卡住的往往是maxmemory配得太紧，或者用了noeviction策略却没控制写入量。
内存碎片率高时，RedisInsight的Memory图表会失真吗
会。当mem_fragmentation_ratio > 1.5（即used_memory_rss_human / used_memory_human > 1.5），RedisInsight显示的used_memory_human仍是准确的，但图表底部的“Memory Usage”总条形图，底层用的是used_memory_rss_human值，这会导致视觉上内存“看起来比实际用得多”。
更隐蔽的问题是：高碎片下，即使used_memory_human远低于maxmemory，used_memory_rss_human也可能触达系统限制，导致OOM Killer干掉进程——而RedisInsight的告警阈值默认只盯used_memory_human。
所以必须手动加一条监控项：mem_fragmentation_ratio，并在RedisInsight的Alerts页面里单独设阈值（建议 >1.4 就告警），不能只依赖内存总量曲线。
