redis集群oom killer杀死节点是因内存碎片率>1.5且rss超maxmemory 2gb+，需同步调优activedefrag四参数、client-output-buffer-limit及hz与淘汰策略。

Redis集群节点被系统OOM Killer杀死，不是Redis自己报OOM错误，而是Linux内核发现该进程实际占用物理内存（used_memory_rss）远超限制，直接干掉进程保系统——这种情况90%以上是内存碎片 + 配置失配共同导致的，重启不解决，必须从mem_fragmentation_ratio和client-output-buffer-limit两个方向同时干预。

怎么确认是OOM Killer动的手，而不是Redis自己拒绝写入

别只看Redis日志。先查系统层证据：

• 执行 dmesg -T | grep -i "killed process"，如果输出里有 redis-server 和 Out of memory，就是OOM Killer干的
• cat /proc/$(pgrep redis-server)/status | grep VmRSS 查当前RSS值，对比 INFO memory 中的 used_memory_rss 是否接近（排除其他进程干扰）
• 如果 mem_fragmentation_ratio > 1.5 且 used_memory_rss 比 maxmemory 高出 2GB+，基本锁定内存碎片是主因

activedefrag yes 为什么开了也拦不住OOM Killer

只设 activedefrag yes 是无效的。它依赖四个参数协同触发，漏一个就静默失效：

Redis Skill - 高性能缓存管理

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

下载

• active-defrag-ignore-bytes：碎片总量不到这个值（如默认 100mb），直接跳过整理 → 实际碎片 80MB 就不干活
• active-defrag-threshold-lower：碎片占比低于这个百分比（如默认 10），不启动 → 碎片率 12% 才开始动，但此时 used_memory_rss 可能已逼近系统内存上限
• active-defrag-cycle-min 和 active-defrag-cycle-max：控制每次整理耗时占比，设太低（如 1）会导致整理速度跟不上碎片生成速度
• 所有参数必须在每个节点上单独执行 CONFIG SET，集群配置同步不会覆盖这些项

client-output-buffer-limit 配得太小会雪上加霜

主节点给从节点发RDB或积压命令时，缓冲区撑爆 → 主动断连 → 重连再积压 → 缓冲区内存不释放 → RSS飙升 → OOM Killer介入。典型症状是 CLIENT LIST 里一堆 omem > 100mb 的连接，且 cmd 字段为空或为 psync。

• 硬限（hardlimit）建议设为 1024mb 或 0（禁用硬限，靠软限兜底）
• 软限（softlimit）设 256mb，软限时长（softseconds）拉到 120 秒，给从节点加载RDB留足时间
• 必须同步调大 repl-backlog-size 至 1024mb，否则从节点一断就连不上，立刻退化全量同步，又回到缓冲区爆炸循环

最容易被忽略的隐性瓶颈：hz 和 maxmemory-policy 组合

hz 控制Redis后台任务（包括淘汰、碎片整理、键过期检查）的执行频率。默认 hz 10 在高负载下可能让碎片整理根本抢不到CPU时间片；而 maxmemory-policy volatile-lru 在没有带TTL的key时完全失效，导致内存无法释放。

• 若业务中大量key未设TTL，必须切到 allkeys-lru 或 allkeys-lfu，否则淘汰策略形同虚设
• 高QPS集群可将 hz 提至 20（注意：会增加CPU开销），确保碎片整理线程有足够调度机会
• 不要依赖 memory purge 命令临时救急——它只对jemalloc生效，且不能解决持续碎片生成问题

真正危险的不是单次碎片率高，而是碎片在后台缓慢累积、缓冲区在同步中反复叠加、淘汰策略在无TTL key场景下彻底失能——这三者一旦形成闭环，OOM Killer就是时间问题，不是会不会，而是哪天动手。