aof重写内存暴增主因是fork的copy-on-write机制触发页拷贝+重写缓冲区累积；可通过info memory差值、日志、aof_pending_rewrite交叉定位；缓解需停自动触发、手动完成重写，并调优auto-aof-rewrite-percentage等参数缩短重写时长。
为什么AOF重写会突然吃掉大量内存？
不是重写过程本身在“分配新内存”，而是 fork 子进程时，操作系统为子进程复制了父进程的页表（Copy-on-Write），只要父进程不改写数据，物理内存仍共享；但一旦父进程持续写入，就会触发大量内存页拷贝——尤其是当 Redis 内存占用已达 10G+、且写请求密集（如每秒 5000+）时，fork 后几秒内 RSS 内存可能飙升 3~5G。
更隐蔽的是：AOF 重写缓冲区（aof_rewrite_buf_blocks）是独立于主 aof_buf 的内存结构，它在重写期间缓存所有新增命令，**不落地、不释放，直到重写完成才一次性追加到新 AOF 文件**。若重写耗时 8 秒、QPS 写入 3000，按平均命令长度 64 字节估算，仅缓冲区就可能占用 8 × 3000 × 64 ≈ 1.5MB——看似不大，但若同时有多个重写未完成（比如被中断后又自动触发），就会堆积成百 MB 的匿名内存，且不体现在 used_memory 中。
怎么查 aof_rewrite_buffer 实际占了多少内存？
Redis 没有直接暴露该缓冲区大小的 INFO 字段，但它属于“未计入 used_memory 的后台任务内存”，可通过以下方式交叉定位：
- 用
redis-cli info memory查看used_memory_rss和used_memory差值：差值持续 > 200MB 且与latest_fork_usec峰值时间吻合，大概率是重写缓冲区 + fork 复制页共同导致 - 查日志：
grep "Background AOF rewrite" /var/log/redis/redis-server.log，关注是否频繁出现 “started” 但无 “completed” 记录——说明重写反复中断，缓冲区不断重建 - 观察
INFO stats中的aof_pending_rewrite：值为1表示已有重写待执行，但尚未开始；若长期为1而aof_rewrite_in_progress为0，说明被阻塞（常见于 bgsave 正在运行或内存不足）
重写期间内存暴增，能临时缓解吗？
不能关重写，但可以切断恶性循环：
- 立即停掉自动触发：动态设置
CONFIG SET auto-aof-rewrite-percentage 0，防止新重写被条件触发 - 手动补一次干净重写：
redis-cli bgrewriteaof，并紧盯日志确认是否成功完成——成功后旧 AOF 被原子替换，缓冲区清空，RSS 会回落 - 如果
bgrewriteaof提交后卡住超过 30 秒，检查系统dmesg | tail是否有 OOM killer 杀 Redis 进程的记录（常见于signal 9终止重写）；若有，说明物理内存确实不足，需降maxmemory或扩容 - 避免在重写时做高写入操作：例如批量
SET、HSET或大量过期 key 集中失效（会生成大量 DEL 命令进缓冲区）
长期配置上，哪些参数真正影响重写内存压力？
关键不在缓冲区大小本身，而在“让它别频繁发生”和“让它别拖太久”：
-
auto-aof-rewrite-percentage别设太高：默认100（翻倍才触发），写入密集场景建议压到50或30，让重写更早、更轻量，避免单次处理数 GB 原始 AOF -
auto-aof-rewrite-min-size要匹配实际数据量：若业务稳定在 2GB AOF，设1gb比64mb更合理，否则小文件也频繁重写，徒增fork次数 - 禁用
appendfsync always：它会让主线程在每次写后fsync，极大拖慢重写速度（因重写进程需等主线程刷盘完成才能安全读取内存状态），用everysec是底线 - 确保
vm.overcommit_memory = 1：Linux 内核参数，允许 fork 时乐观分配内存，避免因 overcommit 拒绝 fork 导致重写失败
重写缓冲区本身不可配大小，它的生命周期完全绑定重写任务——任务越短，它存在时间越短，这才是最有效的“控内存”手段。
