重写期间磁盘峰值占用≈当前aof大小+新aof大小，因旧文件保留、新临时文件写入并存，且内核页缓存隐性占空间；auto-aof-rewrite-min-size应设为aof_base_size的2–3倍，避免频繁重写导致临时文件堆积。
重写期间磁盘空间峰值 ≈ 当前AOF大小 + 新AOF大小
Redis AOF重写不是“原地覆盖”，而是先生成一个新文件（temp-rewriteaof-<pid>.aof</pid>），等写完再原子替换。这意味着：旧AOF文件不能删、新AOF文件正在写，两者同时存在。若当前appendonly.aof是12GB，重写后预计新文件约8GB（因清理过期key、合并命令），那峰值占用就是12GB + 8GB = 20GB——哪怕你磁盘只剩15GB可用，也会卡在No space left on device。
为什么INFO persistence里的aof_current_size不等于实际磁盘占用
aof_current_size只统计AOF主文件字节数，但重写时还有三类额外磁盘开销常被忽略：
- 临时文件：
temp-rewriteaof-*.aof，大小≈重写完成后的目标AOF体积 - 旧AOF残留：重写成功前，原始
appendonly.aof全程保留 - 内核页缓存：Linux会把新AOF写入暂存在内存页缓存中，
df不显示但free -h里buff/cache会涨；若磁盘IO慢，这部分可能长期不刷盘
所以df -h看到剩余10GB，不代表能撑住一次重写——尤其当aof_current_size已是9GB时，临时文件一写就爆。
auto-aof-rewrite-min-size设小了反而更危险
这个值不是“安全下限”，而是“触发门槛”。设成64mb看似保守，但若业务AOF基线（aof_base_size）本身只有50MB，那只要涨到114MB（+128%）就满足条件；频繁重写 → 频繁生成temp-*.aof → 多个临时文件堆积未清理 → 磁盘雪崩。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
正确做法是看INFO persistence输出：
- 记下
aof_base_size: 45678901（上次重写完的大小，单位字节） - 取其2–3倍作为
auto-aof-rewrite-min-size，比如设为107374182（100MB） - 同时确认
aof_current_size是否真远超该值，避免误触发
重写失败后临时文件不会自动清理
子进程因No space left on device或Cannot allocate memory退出时，Redis不会自动删除已写一半的temp-rewriteaof-*.aof。这些“孤儿文件”持续占磁盘，且下次重写又会新建一个——形成恶性循环。
手动清理步骤：
- 停写流量（
CONFIG SET stop-writes-on-bgsave-error yes可临时阻断） - 用
ls -lt data/ | grep temp-rewriteaof找最近的临时文件 - 确认
aof_rewrite_in_progress:0且无redis-cli BGREWRITEAOF在跑，再rm temp-rewriteaof-*.aof - 立刻执行
redis-cli BGREWRITEAOF，观察日志是否出现Background append only file rewriting started
真正棘手的是：重写失败往往发生在磁盘只剩最后几GB时，而rm操作本身需要少量磁盘空间来更新inode——此时可能连rm都报错，得先腾出几百MB才能动刀。
