sar 显示 %iowait 非常高但 iostat 看不出哪个盘特别忙的排查技巧

iowait高但iostat无异常说明I/O等待源于非磁盘环节,需排查容器文件系统、block层延迟、tmpfs/overlayfs等伪设备及内核路径阻塞。

sar 显示 %iowait 非常高但 iostat 看不出哪个盘特别忙的排查技巧

sar 显示 %iowait 持续很高(比如 >30%),但 iostat -x 1 却看不出某块磁盘的 %util、await 或 avgqu-sz 明显异常——这说明 I/O 等待不是来自“典型慢盘”,而是被系统其他环节“吃掉”了,或者 I/O 行为本身很隐蔽。这种情况常见于容器环境、文件系统层开销大、短时突发 IO、或内核路径阻塞等场景。

先确认 iowait 是否真由磁盘 I/O 引起

iowait 高 ≠ 磁盘忙。它只是 CPU 在空闲时等待 I/O 完成的时间占比。所以要排除干扰:

  • 检查 CPU 是否真的有 idle 时间:如果 %idle 极低(如
  • vmstat 1 看 b(blocked 进程数)和 r(runnable 进程数):若 b 长期 >0,说明确有进程卡在不可中断睡眠(D 状态),这才是真 I/O 阻塞信号;
  • 运行 pidstat -u 1pidstat -d 1 对照看:如果 %iowait 高,但各进程的 IO KB/s 和 %io 都很低,大概率是 block 层或驱动层延迟,而非应用写得多。

盯住 block 层和 bio 路径,而不是只看设备层

iostat 只统计到 request queue 层面,对更上游的 bio 分发、合并、调度不敏感。以下命令能挖得更深:

Nimo.space

Nimo.space

智能画布式AI工作台

下载

  • cat /proc/diskstats:对比各设备的 “# of IOs merged”、“# of requests”、“# of sectors read/written”,看是否大量 IO 被 merge 掉,导致 iostat 的 r/s/w/s 失真;
  • blktrace -d /dev/sda -o – | blkparse -i –(需 root):捕获真实下发的 bio 和 request 事件。重点关注 “Q”(queue)、“G”(getrequest)、“C”(complete)之间的时间差。若 Q→G 延迟长,说明 block 层调度/队列深度不足;若 G→C 很长,才指向设备或驱动问题;
  • echo 1 > /sys/block/sda/stat(谨慎)+ 再读一次 /sys/block/sda/stat:可临时触发一次 stat 刷新,辅助判断是否因统计缓存导致 iostat 滞后。

排查 overlayfs、tmpfs、loop 设备等“非物理盘”路径

尤其在 K8s 或 Docker 环境中,高 iowait 常来自文件系统层,而非底层磁盘:

  • 运行 findmnt -t overlay,overlayfs,xfs,ext4,tmpfs,确认是否有 overlayfs 下层(lowerdir/uppperdir)挂载在高 IO 目录;
  • 查容器数据目录是否用了 emptyDirhostPath 绑定到 tmpfs(内存盘):tmpfs 写满会触发 swap 或 OOM Killer,但 iostat 不显示任何磁盘活动;
  • lsof + grep -E “(REG|DEL)” 查高 IO 进程打开的文件路径,重点识别:/var/lib/kubelet/pods/.../volume-subpaths/.../dev/loop*/tmp/xxx ——这些都不是真实磁盘,但会消耗 CPU 在 copy-up、page cache 回写等操作上。

检查内核日志与 multipath/NVMe 特定行为

某些硬件/驱动问题不会让磁盘“忙”,却会让 IO 在途中卡住:

  • dmesg -T | grep -i “block/|nvme/|multipath/|fail/|timeout”:查找 “blk_update_request: I/O error”、“nvme 0000:01:00.0: timeout”, 或 multipath “switching to [path]” 类日志;
  • NVMe 设备注意 cat /sys/class/nvme/nvme0/nvme0n1/queue_depth 和当前 cat /sys/class/nvme/nvme0/nvme0n1/io_poll_delay:队列过浅或轮询延迟设置不当,会导致大量 short-lived IO 在 kernel 中排队,但 iostat 看不出压力;
  • perf record -e block:block_rq_issue,block:block_rq_complete -a sleep 10 + perf script:看 issue → complete 的延迟分布,若大量请求耗时 >10ms 且未落到设备,就说明 block 层或 driver 是瓶颈。

https://www.php.cn/faq/2004793.html

发表回复

Your email address will not be published. Required fields are marked *