判断磁盘i/o瓶颈的核心是%util和await组合：%util持续>90%表明设备饱和，await显著升高（ssd>10ms、hdd>50ms）则反映请求延迟高，二者需联动分析，单看任一指标均易误判。
直接看 iostat -x 1 的 %util 和 await
系统总 IO 负载不是单个数字，而是由多个指标共同反映的。最核心的是 %util 和 await，它们分别回答“设备忙不忙”和“请求等得久不久”。iostat -x 1 每秒刷新一次扩展统计，是最快定位整体压力的方式。
-
%util持续 >90%：说明磁盘设备本身已饱和，I/O 请求排队严重，这是硬瓶颈 -
await显著升高（比如 SSD >10ms、HDD >50ms）：即使%util不高，也可能存在突发队列或调度延迟 - 注意区分设备层级：
sda是物理盘，dm-0或nvme0n1p1是逻辑层，优先看底层物理设备 - 别只盯着一个值：如果
r/s很低但await很高，可能是单次 I/O 请求过大（如大文件顺序读），而非并发高
top 里的 %wa 只能粗略参考
%wa（iowait）是 CPU 在等待 I/O 完成时空闲的时间占比，但它容易误判：
- CPU 核心多、I/O 进程少时，
%wa可能很低，但磁盘本身已满载（%util= 100%） - 某些 NVMe 或异步 I/O 场景下，CPU 不真正“等待”，
%wa接近 0，但iotop显示写入速率极高 - 它反映的是“CPU 等待 I/O”，不是“I/O 设备负载”，二者相关但不等价
用 vmstat 1 看阻塞进程数 b 列
vmstat 1 输出中的 b 列（blocked processes）表示当前因等待 I/O 而不可中断的进程数量，这是系统级 I/O 压力的间接信号：
-
b > 0且持续存在：说明有进程卡在 I/O 上，需结合iostat判断是磁盘慢还是应用行为异常 -
b值突增 +iostat %util同步飙高：基本可确认是磁盘瓶颈 -
b高但%util低：可能卡在 NFS、fuse、或内核锁上，不是本地磁盘问题
别漏掉 iotop -o 定位真实源头
iostat 告诉你“哪里堵”，iotop -o 才告诉你“谁在堵”：
-
sudo iotop -o只显示正在做 I/O 的进程，避免被大量 idle 进程干扰 - 重点看
IO>列（I/O 占用百分比）和DISK WRITE/DISK READ实际速率 - 常见“背锅侠”：
rsyslogd（日志刷盘）、mysqld（刷 redo/log）、java（JVM 日志或临时文件）、dockerd（镜像层写入） - 注意 PID 变化：短生命周期进程（如 cron 脚本）可能一闪而过，要用
iotop -o -b -n 2抓取两轮输出对比
真正难的不是看到数字高，而是判断高得合不合理——同一块 NVMe 盘，%util 95% 跑数据库算正常，跑 rsync 备份就说明配置或路径有问题。盯住设备型号、业务类型、I/O 模式（随机/顺序、读/写比例），才能分清是瓶颈还是误报。
