当前位置：首页 > 文章列表 > 文章 > linux > 如何在Linux中查看磁盘IO的繁忙程度 Linux使用iostat分析IOPS的方法

如何在Linux中查看磁盘IO的繁忙程度 Linux使用iostat分析IOPS的方法

2026-05-24 21:36:12 0浏览收藏

目前golang学习网上已经有很多关于文章的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《如何在Linux中查看磁盘IO的繁忙程度 Linux使用iostat分析IOPS的方法》，也希望能帮助到大家，如果阅读完后真的对你学习文章有帮助，欢迎动动手指，评论留言并分享~

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 是否同步飙升