aof_rewrite_buf_blocks不可配置，其大小由源码硬编码决定；重写失败主因是fork失败、oom或阈值误配，而非该缓冲区小。
aof_rewrite_buf_blocks 不可配置，别白费劲去改它。
Redis 没有暴露任何运行时参数来增大 AOF 重写缓冲区（即 aof_rewrite_buf_blocks），这个缓冲区大小由源码硬编码决定，且随版本变化——你查不到文档、CONFIG GET 也列不出来、CONFIG SET 更会报错。所谓“增加重写缓冲区大小”是常见误解，真正卡住重写的从来不是它。
为什么重写总失败？先看这三个真实信号
别急着调参，先连上 Redis 执行 INFO persistence，盯住这三行：
-
aof_pending_rewrite:1—— 表示重写已排队但没启动，大概率是fork()失败 -
aof_rewrite_in_progress:0但日志里反复出现Background append only file rewriting started by pid XXX然后秒挂 —— 子进程被 kill，通常是 OOM -
aof_current_size和aof_base_size差值巨大（比如 20GB vs 200MB），但就是不触发自动重写 —— 阈值配错，根本没满足“与”条件
fork 失败的典型场景和硬解法
高频写本身不导致重写失败，但会让 fork 更容易崩。原因很实在：子进程需要拷贝父进程页表，而高写入常伴随大内存占用 + THP 启用 + 内核 overcommit 保守。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检查
dmesg | tail -20是否有Out of memory: Kill process XXX (redis-server)或Cannot allocate memory - 关透明大页：
echo never > /sys/kernel/mm/transparent_hugepage/enabled（必须 root，重启失效） - 调内核参数：
sysctl vm.overcommit_memory=1（允许乐观分配，避免 fork 被拒） - K8s 环境重点看 Cgroup 内存限制：如果 Redis 容器 limit 是 20Gi，但重写峰值内存达 22Gi，子进程必被 OOM killer 干掉
auto-aof-rewrite-* 阈值怎么配才不翻车
这两个参数是“与”关系，设错一个，重写就永不到来或天天重写。别抄默认值。
- 先执行
INFO persistence，记下aof_base_size（上次重写完的真实体积） -
auto-aof-rewrite-min-size必须 ≥aof_base_size * 2，例如基线是 800MB，那就设成1600mb；设成64mb就等于告诉 Redis：“只要 AOF 超过 64MB 就重写”，结果每小时生成一堆temp-xxx.aof占满磁盘 -
auto-aof-rewrite-percentage要匹配业务写入节奏：写入突增型（如定时导入）设 200–300；平稳写入型保持 100 即可 - 配完立刻执行
CONFIG REWRITE，否则重启后恢复默认
no-appendfsync-on-rewrite yes 真的能救急吗
能，但只对 appendfsync everysec 有效，且代价明确：重写期间最多丢失 1 秒新写入数据。
- 它不增大任何缓冲区，只是让主线程在重写时跳过
fsync()调用，避免磁盘 I/O 双重压力 - 如果你用的是
always策略，这个配置完全无效 - 生产环境开启前，确认业务能接受秒级数据丢失 —— 支付类系统别碰
重写失败的根因永远在系统层（fork/OOM/磁盘/Cgroup）或配置逻辑（阈值误配），而不是某个“缓冲区太小”。盯着 INFO persistence 和 dmesg，比翻源码改 aof_rewrite_buf_blocks 实在得多。
