info memory可快速定位内存瓶颈：关注used_memory、used_memory_rss及mem_fragmentation_ratio（=used_memory_rss/used_memory）三者关系；ratio＞1.5表明碎片严重，应优先memory purge；ratio≈1.0但used_memory逼近maxmemory时，才需调整淘汰策略。

如何用 INFO memory 快速定位内存瓶颈

直接运行 redis-cli INFO memory 是最轻量、最可靠的起点。关键不是看总量，而是盯住三个指标的组合关系：

• used_memory：Redis 自己统计的数据内存用量（不含碎片和进程开销）
• used_memory_rss：操作系统看到的物理内存占用
• mem_fragmentation_ratio = used_memory_rss / used_memory

如果 mem_fragmentation_ratio > 1.5，说明内存碎片严重，memory purge 可能比换淘汰策略更有效；如果接近 1.0 但 used_memory 持续逼近 maxmemory，那才是淘汰策略该介入的时候。

redis-cli --bigkeys 为什么比 KEYS * 安全

KEYS * 是阻塞式全量扫描，生产环境禁用；而 redis-cli --bigkeys 基于 SCAN 游标分批执行，不阻塞主线程，且自动按数据结构分类统计 Top N 大 key。

Redis Skill - 高性能缓存管理

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

下载

• 它会告诉你哪些 Hash 超过 10KB、哪些 List 长度超过 1000 —— 这些正是淘汰策略“踢不动”的对象（大 key 删除耗时长，容易拖垮周期性淘汰）
• 输出里带 avg_element_size 和 entries，能帮你判断是单个 value 过大（如未压缩 JSON），还是集合类结构膨胀（如日志 List 不清理）
• 注意：它只分析当前 DB，跨 DB 需手动切换 -n 参数

淘汰策略选错的典型症状与修正方向

不是所有内存压力都靠换策略解决。先看现象再动配置：

• 写请求频繁返回 (error) OOM command not allowed when used memory > 'maxmemory'，但 ttl 查大量 key 有剩余时间 → 说明过期键没被及时清理，优先调高 hz（默认 10，可试 20–50），而不是换 volatile-ttl
• 缓存命中率断崖下跌，evicted_keys 指标飙升，但 keyspace_hits / keyspace_misses 比例正常 → 很可能是 allkeys-lru 把刚写入的热 key 提前踢了，换成 allkeys-lfu 更稳
• 大量 key 本不该过期（如用户 session），却总被 volatile-lru 淘汰 → 检查是否误给这些 key 设了 EXPIRE，或者混用了 SET 和 SETEX

MEMORY USAGE 和 MEMORY STATS 的真实用途

MEMORY USAGE key 返回单个 key 的精确内存占用（含编码开销），但它不能替代整体分析 —— 因为 Redis 内部元数据、连接缓冲区、Lua 栈等不计入其中。

• 真正要查“为什么某个 Hash 占 5MB”，得配合 DEBUG OBJECT key 看编码类型（listpack vs hashtable）和元素数量
• MEMORY STATS 的 peak.allocator_bytes 和 allocator_active 才反映 jemalloc 实际分配状态，比 used_memory 更贴近底层
• 别依赖 redis-cli --in-memory-optimize：它只是对 key 做 rehash 减少哈希表空槽，对大 value 或复杂嵌套结构无效

淘汰策略生效的前提是内存真到了临界点，而不是指标看起来高。很多所谓“内存问题”，根源在大 key 持久存在或过期机制失灵，调策略只是掩盖症状。