iostat -x 是判断磁盘真实繁忙程度的可靠起点，因其 r_ios/w_ios 统计驱动层真实下发请求，rMB/s/wMB/s 反映绕过缓存的实际吞吐，结合 await、avgrq-sz 和 %util 才能准确定位排队或响应瓶颈。
iostat -x 是判断磁盘是否真正繁忙的起点，其他方式（比如只看 r/s、w/s 或 %util 单独值）容易误判——因为它们要么被上层合并扭曲，要么没排除缓存干扰，要么忽略等待队列堆积。
为什么 iostat -x 才能反映真实 IOPS 和繁忙程度
普通 iostat 输出的 r/s 和 w/s 是 VFS 层统计的逻辑请求次数，会被 page cache、IO scheduler 合并或延迟下发；而 iostat -x 的 r_ios 和 w_ios 是驱动层上报的真实下发到设备的 I/O 次数，才是可比的 IOPS。
-
r_ios/w_ios：单位是「次/秒」，对应物理设备真实处理的读写请求数 -
rMB/s/wMB/s：绕过 page cache 的吞吐，单位统一为 MB，和厂商标称值可比 -
%util接近 100% 且await> 50ms → 不是磁盘“慢”，而是请求在队列里堵住了 -
avgrq-sz若长期
iostat -x 的典型执行与关键字段识别
运行 iostat -dx 2 3（每 2 秒刷新一次，共 3 次），跳过首行冷启动噪音，重点关注以下列：
-
Device：确认设备名，如sda、nvme0n1、vda（云环境常见） -
r_ios/w_ios：真实读写 IOPS，加起来就是总 IOPS -
rMB/s/wMB/s：真实吞吐，不是rkB/s那种带缓存干扰的旧单位 -
%util：持续 ≥ 80% 表示设备饱和；但注意：NVMe 设备支持多队列，%util可能失真，此时更要看await和avgqu-sz -
await：> 10ms 就需警惕，> 50ms 基本确认存在排队瓶颈
常见误判场景与避坑点
看到高 r_ios 就断定“磁盘扛不住”？未必。很多问题出在观察维度或理解偏差：
- 只跑
iostat不加-x→ 把r/s当 IOPS，结果比实际低 3–10 倍（尤其在日志轮转、数据库 checkpoint 场景下） - 用
rkB/s算吞吐 → 它包含 page cache 缓存命中流量，无法反映真实落盘压力 - 发现
%util只有 30%，就认为“不忙” → 错！若await达到 200ms，说明单个请求等了很久，只是并发不高而已 - 在 KVM 虚拟机里看
iostat -x→r_ios是 guest kernel 发给 virtio-blk queue 的次数，不等于宿主机物理 SSD 的 NAND 操作次数 - 忽略
rrqm/s和wrqm/s→ 如果合并率 > 70%，说明上层 IO 是顺序/可聚合的；如果几乎为 0，大概率是随机小 IO，优化方向完全不同
当 iostat -x 显示繁忙，下一步该做什么
iostat -x 告诉你「哪里忙」和「有多忙」，但不告诉你「谁干的」。必须立刻切到进程层：
- 新开终端，运行
sudo iotop -o -P，聚焦正在真实刷盘的用户态进程 - 若
iotop空白或全是 0.00B/s → 检查是否以 root 运行、内核是否启用CONFIG_TASKSTATS（zcat /proc/config.gz 2>/dev/null | grep TASKSTATS） - 对准高
r_ios设备，用df -h查其挂载点，再用lsof +D /mnt/data 2>/dev/null看哪些进程在访问该路径下的文件 - 临时验证：用
dd if=/dev/zero of=/mnt/data/test bs=4k count=10000 oflag=direct+sync模拟小块直写，观察iostat -x 1中r_ios和await是否同步飙升
%util 对传统 SATA 是硬门槛，对 NVMe 就只是参考；await 在云环境中还混杂了网络存储协议开销。别跳过设备类型确认这一步。 
