怎样通过Redis日志排查内存淘汰异常_分析maxmemory限制下的日志输出-Redis-PHP中文网

不是物理内存真正耗尽，而是redis触发写入拒绝机制：原因包括内存碎片率过高（>1.5）、maxmemory-policy为noeviction、集群单节点超限、maxmemory配置过低或缓冲区隐式占满。

怎样通过redis日志排查内存淘汰异常_分析maxmemory限制下的日志输出

直接看日志里有没有 OOM command not allowed when used memory > 'maxmemory' —— 有，就是内存写满被拒了；没有，别急着调 maxmemory，可能根本没到阈值。

这个错误不是“快满了”，而是“已经满了且策略不允许淘汰”，必须立刻验证两个数值：

used_memory 和 maxmemory 是否真的接近（比如差值 redis-cli -p 6379 INFO memory | grep -E "(used_memory|maxmemory)" 查
mem_allocator 是否为 jemalloc（主流），避免误判内存碎片导致的伪 OOM
检查 evicted_keys 计数器是否为 0：如果是 0，说明淘汰策略压根没生效（比如配了 volatile-lru 但所有 key 都没 TTL）
注意日志时间戳和 INFO stats 中的 latest_fork_usec：如果刚 fork 过，used_memory 可能含 copy-on-write 内存，实际物理占用未必真爆

不同淘汰策略触发时，Redis 日志行为完全不同，不能只盯 OOM 错误：

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

下载

noeviction（默认）：只报 OOM，evicted_keys 永远为 0，expired_keys 不受影响
volatile-lru 或 volatile-ttl：若 evicted_keys 为 0 但 used_memory_human 接近 maxmemory_human，大概率是业务写入的 key 全都没设 TTL，策略失效
allkeys-lru 或 allkeys-lfu：会持续增加 evicted_keys，但日志里通常不打具体淘汰了谁——得靠 redis-cli --bigkeys 或 MEMORY USAGE 手动查大 key
volatile-random / allkeys-random：不会产生明显日志特征，但 evicted_keys 会涨，需结合监控看突增是否匹配业务批量写入节奏

运行时调大 maxmemory 后，旧的 OOM 错误可能还会持续几秒，原因很实际：

客户端连接可能复用旧的连接池配置，部分请求仍按旧阈值校验（特别是 Jedis/Lettuce 未刷新连接状态时）
Redis 的内存统计是周期性采样（默认每 100ms 更新一次 used_memory），刚改完还没来得及重算
如果之前触发过 evict 流程，正在异步释放 bigkey，释放过程本身会卡住命令队列，新请求继续排队等，看起来像“没生效”
CONFIG SET maxmemory-policy 必须在 maxmemory 已设的前提下才起作用；单独改策略、不设 maxmemory，等于没开淘汰开关

OOM 错误只是结果，真正该实时监控的是这几个字段：

used_memory_peak_human：历史峰值，比当前 used_memory 更能暴露突发写入问题
mem_fragmentation_ratio > 1.5 时，说明内存碎片严重，used_memory 看似没满，但实际分配失败频繁
expired_keys 短时间暴涨（比如 1 秒内 +1000），可能触发集中过期 + 淘汰双重压力，延迟飙升
evicted_keys 持续非零增长，但 used_memory 不降反升 → 很可能是写入速度远超淘汰速度，或者淘汰的都是小 key，腾不出足够空间