如何排查Redis持久化导致的系统负载过高（iostat与strace）

遇到高Load，最直接的反应就是敲下iostat -x 1，然后盯死那面“仪表盘”。但很多人容易被rkB/s和wkB/s这些流量数据带偏，其实真正需要关注的核心指标只有两个：%util（磁盘繁忙度）和await（平均IO响应时间）。

• 如果%util > 90%且await > 20ms，别犹豫了，这说明磁盘已经饱和，IO请求排着长队在等队长派活。高Load的根源不是Redis处理慢了，而是数据写不进去磁盘。
• 一个常见的误判是：%util很高，但await却很低（比如10ms以内甚至为-1）。这看似矛盾，但恰恰说明问题不在磁盘本身，而是底层存储的响应就是快，只是请求太多把总线塞满了。这时要配合pidstat -d 1确认，是不是Redis进程在疯狂发IO。
• 更危险的一种情况：await飙到几十毫秒，但%util只有60%~70%感觉“还有余地”。这其实是IO请求已经在队列里排队了，只不过磁盘服务端还能应付。这通常出现在appendfsync everysec和AOF rewrite双写叠加时。

当然，如果有多实例共享一块盘的情况，记得加上-d /dev/nvme0n1指定设备，否则看到的只是全盘统计，单实例的真实压力被掩盖了。

iostat只能告诉我们“磁盘累了”，但它不会告诉我们“是谁干的”。这个时候，就要请出strace这位大侦探了。关键点在于：执行RDB或AOF rewrite写盘的是Redis fork出来的子进程，主进程虽然还在，但它只是个“甩手掌柜”。所以直接用strace -p挂主进程PID，纯粹是白费功夫。

正确操作步骤是：

1. 阅读Redis日志（通常位于/var/log/redis/redis-server.log），找到类似Background saving started by pid 12345或Starting automatic rewriting of AOF的行，锁定那个子进程的PID。
2. 立刻执行：strace -T -e trace=write,fsync,fdatasync -p 12345 -o /tmp/redis_io.strace。注意不要加-f，因为子进程生命周期很短，且AOF rewrite子进程不会再次fork，加了反倒可能干扰。
3. 重点观察write系统调用的耗时和返回值。如果大量write耗时超过10ms，甚至返回-1 EAGAIN，说明底层存储响应太慢。如果fsync阻塞时间超过50ms，那基本可以锁定，罪魁祸首就是磁盘延迟。

这是个非常经典的“灯下黑”问题。很多同学百思不得其解：为什么top里wa%（IO等待）高得吓人，但用redis-cli INFO却看到used_memory、connected_clients、甚至instantaneous_ops_per_second都完全正常？

其实原因很简单：INFO反映的是Redis的用户态逻辑状态，它只是“在自己的世界里一切正常”。而wa%是内核统计的进程等待IO完成的时间。此时，Redis主进程在做什么？它在等待子进程完成fsync并退出，自己处于S（sleep）状态，所以top里看不到CPU占用，但Load和wa%已经拉满了。

这时，必须多维度交叉验证：

• 查配置：redis-cli config get save和config get auto-aof-rewrite-percentage，确认RDB/AOF触发条件是否过于激进（比如save 60 10000在写入密集时，每分钟都在dump）。
• 看内核栈：cat /proc/$(pgrep redis-server)/stack，如果主进程当前内核栈停在wait_event_interruptible或do_wait，那就是在等子进程退出。
• 查IO分布：pidstat -p $(pgrep redis-server) -d 1，如果观察到主进程的MB/s几乎为0，但子进程的写入量很高，那就是典型的“父等子”模式。

排查这类问题，最怕的就是“只见树木，不见森林”。除了上面这些常规操作，还有三个点很容易中招：

• 时间戳未对齐：Redis日志里的时间戳和iostat的采样周期可能差了3秒。看到IO出现尖峰，却找不到对应的日志条目，其实是时间轴没对上。所有监控必须手工用date +%s.%N打上精确时间戳，别信系统默认格式。
• IO来源混淆：AOF rewrite期间，主进程仍然在往旧的AOF文件追加写入。这部分IO和rewrite的IO混在一起，iostat看到的是总和。必须借助strace区分每个write、fsync调用的来源，不然会误判。
• 云盘指标失真：有些云盘（比如AWS的gp3）提供的%util指标本身就不太准，它反映的是EBS服务端的队列情况，而不是本地NVMe设备。这时候，改用iotop -a看实际进程的IO权重，反而更直接有效。