怎样在Redis中监控AOF重写的实时进度与资源开销-Redis-PHP中文网

aof重写是否执行需查info persistence中aof_rewrite_in_progress=1；其进度不可实时获取，仅能通过aof_current_rewrite_time_sec、临时文件大小及系统io/cpu指标间接观测，无内置key级进度统计。

怎样在redis中监控aof重写的实时进度与资源开销

Redis本身不提供AOF重写过程的实时进度百分比，但可通过组合命令和指标间接观测状态与开销。

如何判断AOF重写是否正在执行

直接查 INFO persistence 的输出字段：

aof_rewrite_in_progress:1 表示当前有重写子进程在运行；为 0 则没有
aof_rewrite_scheduled:1 表示重写已被调度但尚未开始（例如因 no-appendfsync-on-rewrite yes 正在等待 fsync 完成）
aof_current_rewrite_time_sec 是已运行秒数，可粗略反映耗时趋势（但不等于总耗时，因为可能被中断或暂停）

重写期间的内存与IO开销怎么看

AOF重写由子进程完成，其资源消耗主要体现在三方面：

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

内存：子进程会 fork，触发写时复制（COW），实际内存占用取决于重写开始时刻的 Redis 内存脏页量。用 INFO memory 对比 used_memory 和 used_memory_rss 差值突增，是典型信号
CPU：重写本身是 CPU 密集型操作，尤其 key 数量大、value 复杂时。观察系统级 top -p $(pgrep -f "redis-server.*aof") 或 ps aux | grep "redis.*rewrite"
磁盘IO：重写生成新文件是顺序写，但若同时开启 appendfsync always 或 everysec，主线程与子进程会竞争磁盘带宽。用 iostat -x 1 看 %util 和 await 是否飙升

为什么不能像RDB那样用bgsave_info查进度

因为 AOF 重写没有暴露类似 bgsave_in_progress 那样的原子状态字段，也没有内置计数器记录“已处理多少key”。它的实现逻辑是遍历当前数据库键空间，逐个序列化最新值，不维护中间进度快照。所以：

redis-cli info persistence | grep aof 只能告诉你“在不在干”，不能告诉你“干到哪了”
不要依赖 aof_base_size 和 aof_current_size 差值估算进度——这两个是触发条件阈值，不是实时大小
若需精确监控，得靠外部手段：比如定期 du -h appendonly.aof.*.temp（重写临时文件名通常带 .temp 后缀），但要注意该文件仅在重写中存在，且权限受限

真正容易被忽略的是：AOF重写过程中，如果配置了 auto-aof-rewrite-percentage 触发机制，而新写入又非常频繁，可能导致连续重写被反复调度，形成“重写风暴”。此时 aof_rewrite_scheduled 会长时间为 1，但 aof_rewrite_in_progress 在 0 和 1 之间跳变，必须结合日志（grep "Background AOF rewrite" redis.log）交叉验证。