Redis 内存明明没满却报 OOM：maxmemory、碎片率与客户端输出缓冲核对

线上 Redis 返回 OOM command not allowed when used memory > 'maxmemory' 时，先别只看监控面板上的“已用内存”。Redis 的淘汰判断、分配器保留的 RSS、客户端输出缓冲和大 key 会落在不同的观测口径里；其中任何一项没有对上，都可能出现“看起来还没满，写入却失败”。

先把 Redis 的“内存没满”拆成三种口径

最容易误判的是把操作系统的 RSS 图表当成 Redis 的淘汰计数，或者反过来只看 used_memory。先执行：

redis-cli INFO memory | egrep 'used_memory:|used_memory_rss:|used_memory_peak:|maxmemory:|maxmemory_policy:|mem_not_counted_for_evict:|mem_fragmentation_ratio:'

used_memory 表示 Redis 记录的已分配内存，used_memory_rss 是进程从操作系统角度占用的常驻内存，maxmemory 是配置的逻辑上限。RSS 比逻辑占用高，并不等于 Redis 已经把可淘汰数据算满；这通常与 jemalloc 碎片、释放后未立即归还内核有关。

maxmemory 之外的占用要看 mem_not_counted_for_evict

如果实例开启了复制或 AOF，复制缓冲、AOF rewrite 缓冲等内存可能不计入淘汰判断，但仍然会挤压进程的整体资源。INFO memory 中的 mem_not_counted_for_evict 是第一处核对点：

redis-cli INFO memory | egrep 'mem_not_counted_for_evict|mem_clients_normal|mem_clients_slaves|mem_aof_buffer|mem_replication_backlog'

不要把这个字段简单加到 used_memory 上就当作 Redis 的精确 OOM 公式。它更适合回答“有多少内存没有进入淘汰空间”。同时检查 maxmemory-policy：如果是 noeviction，可写命令在达到上限后会直接失败；如果是 allkeys-lru 或 volatile-ttl，还要确认确实存在可淘汰的键。

碎片率高时，先判断是暂时保留还是持续增长

可以用一个粗略信号观察分配器状态：

redis-cli INFO memory | egrep 'used_memory:|used_memory_rss:|mem_fragmentation_ratio:'
redis-cli MEMORY STATS

mem_fragmentation_ratio 明显高于 1，常见原因是大量不同尺寸的 key 反复创建和删除。它说明 RSS 相对逻辑分配偏高，但不表示可以无条件执行整理操作。先确认业务写入仍在增长，观察 used_memory_peak、RSS 和 key 数量的趋势；如果逻辑内存已经接近 maxmemory，优先处理数据生命周期和淘汰策略，而不是只盯着碎片率。

如果实例允许维护窗口，可以在确认没有并发大对象操作的前提下评估 MEMORY PURGE。它影响的是分配器可归还的空闲页，不能删除业务 key，也不能替代对大 key 和客户端缓冲的排查。

客户端输出缓冲可能把最后一段空间吃掉

普通命令客户端、订阅客户端和副本客户端的输出缓冲都可能不同。先看全局统计，再找异常连接：

redis-cli INFO clients | egrep 'connected_clients|blocked_clients|client_recent_max_input_buffer|client_recent_max_output_buffer|mem_clients_'
redis-cli CLIENT LIST

在 CLIENT LIST 中重点看 omem（输出缓冲字节数）、obl、oll、cmd 和连接地址。某个订阅者长期不读消息，或者一次查询返回很大的集合，都会让 omem 持续上升。Redis 7.2 之后还可以结合 maxmemory-clients 观察客户端缓冲是否有独立上限；不要为了消除告警直接踢掉所有业务连接。

最后用 MEMORY USAGE 找出真正的大 key

全量扫描会给生产实例带来额外压力，先用抽样式的 --bigkeys 找方向，再对候选 key 精确测量：

redis-cli --bigkeys -i 0.01
redis-cli MEMORY USAGE 'cache:feed:user:10086' SAMPLES 10

--bigkeys 按数据类型报告采样到的最大对象，MEMORY USAGE 返回单个 key 的近似字节数。对 Stream、Hash、Sorted Set 等结构，还要结合成员数量和访问模式判断是否应拆分；直接删除大 key 可能造成同步阻塞，可以采用分批删除或在业务低峰使用异步删除策略，并观察延迟和复制积压。

一条不容易误伤生产的处理顺序

1. 保存 INFO memory、INFO clients、CONFIG GET maxmemory* 和错误时间点，先固定观测口径。
2. 核对 maxmemory-policy 与可淘汰键类型；noeviction 场景不要误以为系统会自动清理。
3. 检查 mem_not_counted_for_evict、AOF/复制缓冲和 CLIENT LIST 的 omem，把额外占用归类。
4. 对大 key 做抽样和分批处理，记录处理前后的延迟、RSS、复制偏移和错误率。
5. 最后再评估修改 maxmemory 或淘汰策略，并为回滚保留原配置。

常见问题

used_memory 没到 maxmemory，为什么写命令仍然 OOM？

先确认错误是否来自 Redis 本身，再核对实际生效的 maxmemory、策略和命令类型。复制/AOF缓冲、客户端输出缓冲或策略为 noeviction 都可能改变写入结果，不能只看一个监控指标。

mem_fragmentation_ratio 高是不是马上要重启？

不一定。先看逻辑内存、RSS、峰值和趋势；短时删除潮可能留下可复用的分配器空间。重启会带来切换和恢复成本，应把它作为有计划的维护动作，而不是碎片率单指标触发器。

CLIENT LIST 里的 omem 很大怎么处理？

先按连接的 cmd、地址和业务角色确认慢消费者，再降低单次响应规模、修复订阅读取或设置合适的客户端缓冲策略。直接批量断连接可能造成重连风暴。

maxmemory-policy 改成 allkeys-lru 就不会 OOM 了吗？

不能保证。实例可能没有足够可淘汰键，复制/AOF和客户端缓冲也不等于普通缓存数据。策略变更前要确认数据是否允许丢弃，并用压测或灰度观察命中率、延迟和错误率。

收尾核对

Redis OOM 的排查重点不是找一个“神奇阈值”，而是把逻辑数据、分配器 RSS、淘汰外内存、客户端缓冲和大 key 放回同一条时间线上。留下同一时刻的命令输出与配置快照，再做调整，通常比直接扩大内存上限更快找到根因。