直接看%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 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先查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权重。
