RedisAOF重写内存占用监控技巧

Redis AOF重写期间内存暴增并非源于重写逻辑本身大量分配内存，而是由fork的Copy-on-Write机制在高负载下触发大规模页拷贝，叠加AOF重写缓冲区（不计入used_memory、不落地不释放）持续累积写命令所致；通过对比info memory中used_memory_rss与used_memory的差值、分析日志中的重写启停记录及aof_pending_rewrite等指标可精准定位问题，临时可通过禁用自动触发、手动完成重写并规避高写入操作快速缓解，长期则需调优auto-aof-rewrite-percentage/minimum-size、禁用appendfsync always并确保内核overcommit配置合理——核心思路是“让重写更早、更轻、更快”，从而压缩缓冲区存活时间与fork冲击窗口。

为什么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 导致重写失败

重写缓冲区本身不可配大小，它的生命周期完全绑定重写任务——任务越短，它存在时间越短，这才是最有效的“控内存”手段。

终于介绍完啦！小伙伴们，这篇关于《RedisAOF重写内存占用监控技巧》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布数据库相关知识，快来关注吧！