used_memory_overhead 是 Redis 中存储 key 元信息、底层结构开销及客户端缓冲区等非数据内存，它不参与 allkeys-lru 淘汰，导致即使触发淘汰也无法释放足够空间，从而出现 OOM。
used_memory_overhead 是什么，为什么它会导致 allkeys-lru 失效
used_memory_overhead 是 Redis 内存模型中容易被忽略但极关键的一部分：它不存业务数据，而是记录每个 key 的元信息（如类型、编码、过期时间指针、LRU/LFU 时间戳）、dict 和 ziplist 等底层结构的管理开销、以及客户端缓冲区、复制积压缓冲区等非数据内存。当 key 数量极大（比如千万级小 key），哪怕每个 key 只占几字节 value，used_memory_overhead 也可能高达几 GB。
问题就出在这里：allkeys-lru 只对「数据内存」做淘汰——即 used_memory - used_memory_overhead 这部分；而 maxmemory 限制的是总内存（含 overhead）。如果 overhead 占了 70%，剩下 30% 全是小 key 的 value，那么即使你删掉所有 value，也腾不出足够空间满足新写入——因为 overhead 本身无法被 LRU 淘汰。
验证方式很简单：
redis-cli info memory | grep -E "used_memory|overhead"
若 used_memory_overhead / used_memory > 0.4，且 mem_fragmentation_ratio 正常（1.0–1.5），基本可判定是 overhead 吃掉了弹性空间。
怎么快速定位 overhead 高的根源
不是所有 key 都平等贡献 overhead。以下三类是“overhead 富集区”：
-
KEYS *或SCAN扫描后用MEMORY USAGE逐个查，会发现大量string类型小 key（如user:123:status）单个 overhead 占比超 80% - 用
redis-cli --bigkeys时注意输出里 “(average) overhead per key” 这一列，值 > 200 字节就要警惕 - 检查
INFO clients中client_longest_output_list和client_biggest_input_buf，若持续 > 1MB，说明某些客户端卡住，obuf 持续膨胀计入 overhead - 执行
CLIENT LIST查看obuf字段，筛选出obuf=值异常大的连接（如 > 512KB），它们可能在慢消费 Pub/Sub 或阻塞命令响应
overhead 过大时 allkeys-lru 为什么看起来“没反应”
这不是策略失效，而是淘汰逻辑被底层限制卡住了。Redis 在每次淘汰前会预估「释放一个 key 能净腾出多少内存」，这个估算只包含 value + 编码开销，**不减去 key 元信息本身的 overhead**。所以当你有 1000 万个 key，每个 key overhead 200B、value 10B，Redis 认为删一个只能腾 10B，但实际要删 10 万个才能凑够 1MB——而淘汰过程是单线程串行执行的，来不及跟上写入速度。
表现就是：
- 写入报
OOM command not allowed when used memory > 'maxmemory'，但INFO stats中evicted_keys几乎不增长 -
INFO memory显示used_memory_peak接近maxmemory，而used_memory_dataset（Redis 7.0+）远小于该值 - 用
redis-cli --memkeys抽样，发现 top 100 key 的overhead总和占比超 60%
绕过 overhead 瓶颈的实操手段
不能指望 LRU 自动解决，得主动干预：
- 紧急止损：用
SCAN+DEL批量清理已知无用 key 前缀，例如SCAN 0 MATCH "tmp:*" COUNT 1000，避免KEYS *阻塞 - 降低单 key 开销：把高频小 key 合并成 Hash（如
HSET user:123 status online last_seen 1712345678），一个 Hash 的 overhead ≈ 1 个 key，但能存上百字段 - 控制客户端行为：对长连接客户端设置
client-output-buffer-limit，例如config set client-output-buffer-limit "normal 256kb 256kb 60"，防obuf失控 - 升级到 Redis 7.0+：启用
active-defrag-ignore-bytes 100mb并打开activedefrag yes，它能在碎片整理时一并 compact 小 key 的 dict 结构，间接压低 overhead
overhead 不像大 key 那样一眼可见，它藏在千万级 key 的毛细血管里——排查时别只盯着 value 大小，先看 used_memory_overhead 占比，再顺藤摸瓜找 key 密度和客户端缓冲区。
