如何排查Redis持久化导致的系统Load过高?使用iostat和strace跟踪系统调用

直接看%util和await两列：若%util>90%且await>20ms，说明磁盘已饱和，Redis持久化正在拖垮磁盘；%util高但await低（如10ms或-1）表明底层存储响应慢，fsync超50ms可锁定为磁盘延迟。

iostat怎么看Redis持久化是否在拖垮磁盘

直接看%util和await两列，别被rkB/s或wkB/s带偏。Redis RDB或AOF rewrite触发时，磁盘IO是“突发型”或“持续型”，但只要%util > 90%且await > 20ms，基本就能断定磁盘已饱和，Load高不是Redis慢，而是写不进去。

常见误判点：

• %util高但await始终 pidstat -d 1确认是不是Redis进程真正在发IO
• 多个Redis实例共用一块盘：必须加-d /dev/nvme0n1指定设备，否则iostat -x 1看到的是全盘统计，掩盖了单实例压力
• 看到await飙升但%util只有60%~70%：更危险——说明IO请求在队列里排队，典型于appendfsync everysec + AOF rewrite双写叠加

strace怎么抓Redis子进程的IO行为

Redis fork子进程做RDB或AOF rewrite，主进程PID不变，但实际写盘的是子进程。用ps -ef | grep redis只能看到主进程，strace -p挂错对象就白忙。

正确做法：

• 先查Redis日志，找到类似Background saving started by pid 12345或Starting automatic rewriting of AOF的行，记下那个pid（这是子进程PID）
• 立刻执行：strace -T -e trace=write,fsync,fdatasync -p 12345 -o /tmp/redis_io.strace
• 别加-f：fork后的子进程生命周期短，-f容易漏掉关键write调用；AOF rewrite子进程不会再fork，不需要跟踪子孙
• 重点关注write返回值和耗时：如果大量write耗时 > 10ms 或返回-1 EAGAIN，说明底层存储响应慢；fsync阻塞超50ms，基本可锁定是磁盘延迟

为什么top里wa%高但Redis INFO显示正常

因为INFO里的used_memory、connected_clients、甚至instantaneous_ops_per_second都反映的是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，就是在等子进程退出
• pidstat -p $(pgrep redis-server) -d 1中观察Blk_dev列，若主进程MB/s几乎为0但子进程很高，就是典型的“父等子”模式

排查时最容易忽略的三个点

一是Redis日志时间戳和iostat时间没对齐，看到IO尖峰却找不到对应日志，其实差了3秒——所有监控必须用date +%s.%N打标，别信系统默认格式；二是AOF rewrite期间主进程仍往旧AOF追加，这部分IO和rewrite IO混在一起，iostat看到的是总和，必须靠strace区分调用来源；三是有些云盘（如AWS gp3）的%util指标本身不准，它反映的是EBS服务端队列，不是本地NVMe设备，得结合iotop -a看实际进程IO权重。