Redis-server被OOM kill但进程仍在，是AOF重写子进程被杀：查/var/log/messages或dmesg确认被杀PID，再进Redis数据目录找temp-rewriteaof-PID.aof文件，若PID一致即可锁定；主进程used_memory不反映AOF缓冲内存，需关注mem_aof_buffer和used_memory_rss。
redis-server被OOM kill但进程还在，怎么看是AOF重写子进程的问题
直接查/var/log/messages或dmesg，看到类似Killed process 18665 (redis-server) score 919的记录后，别急着查主进程——那个18665很可能是子进程PID。进Redis数据目录找temp-rewriteaof-*.aof文件，文件名后缀如果和被kill的PID一致（比如temp-rewriteaof-18665.aof），基本就能锁定是AOF重写期间子进程因内存不足被系统干掉。
常见误判点：
- 只看
redis-cli INFO memory里的used_memory，它不包含AOF重写缓冲区占用 - 忽略
mem_aof_buffer指标，这个字段才反映当前AOF写缓冲实际内存开销 - 用
ps aux看RSS时没注意子进程，主进程RSS可能正常，但子进程已吃光剩余内存
怎么确认AOF重写期间的内存压力来源
AOF重写本身不直接分配大量内存，但它会触发两个关键内存消耗点：一是子进程fork后COW机制导致的物理内存复制（尤其当used_memory_rss远大于used_memory时更明显）；二是重写过程中新写入命令必须暂存在内存缓冲区，直到重写完成再追加到新AOF文件——这部分由mem_aof_buffer体现。
实操建议：
- 重写前先执行
redis-cli INFO memory | grep -E "used_memory|mem_aof_buffer|mem_clients"，记下基线值 - 触发
BGREWRITEAOF后，每10秒跑一次上面命令，观察mem_aof_buffer是否飙升（比如从几MB涨到2GB+） - 同时用
cat /proc/$(pgrep redis)/status | grep VmRSS对比主进程和子进程的RSS变化 - 如果
mem_aof_buffer增长缓慢但RSS暴涨，重点查内存碎片率mem_fragmentation_ratio是否＞1.5
哪些配置会让AOF重写更容易OOM
no-appendfsync-on-rewrite no是最大隐患：它让重写期间仍强制fsync新写入，导致AOF缓冲区无法及时刷盘，持续堆积。而默认appendfsync everysec在重写时若不关闭，缓冲区就变成“只进不出”的黑洞。
容易被忽略的组合风险：
-
auto-aof-rewrite-percentage设得过高（如300），等触发时AOF已极大，重写过程更久、缓冲区堆积窗口更长 -
client-output-buffer-limit slave和repl-backlog-size没同步调大，主从断连引发全量同步，进一步挤占内存 - 没开
activedefrag yes，内存碎片高导致used_memory_rss虚高，留给AOF缓冲的余量实际更少 -
dir路径所在磁盘空间不足，重写时既要写新AOF又要保留旧AOF，磁盘IO阻塞加剧内存缓冲堆积
临时止血和长期规避怎么做
线上已OOM时，优先保服务：停掉AOF重写，切到RDB恢复路径。运行redis-cli CONFIG SET appendonly no无效（进程已挂），必须用启动参数绕过：redis-server --appendonly no，起来后立刻BGSAVE生成新RDB，再切回AOF。
长期配置要点：
- 把
no-appendfsync-on-rewrite yes加入配置，重写期间暂停fsync，靠操作系统page cache扛住写入 -
auto-aof-rewrite-min-size至少设为64mb，避免小文件频繁重写；auto-aof-rewrite-percentage按写入节奏调，高频服务建议50而不是默认100 - 监控项必须加
mem_aof_buffer和aof_current_size，阈值告警设为内存总量的15%（不是固定值） - 重写期间禁止人为触发
BGREWRITEAOF，删掉所有定时任务——很多OOM都是运维脚本半夜偷偷干的
最常漏掉的一点：CONFIG REWRITE之后必须确认配置文件落地，否则重启就回到原点。检查redis.conf里是否真写了no-appendfsync-on-rewrite yes，别只信CONFIG GET返回的结果。
