iostat -x 1是查看真实IOPS（r_ios/w_ios）和吞吐量（rMB/s/wMB/s）的唯一合理起点，因r/s、w/s等指标受缓存和请求合并干扰而失真；await超阈值（HDD>10–15ms、SSD>2–5ms）需结合%util与avgqu-sz判断瓶颈位置。
没有 diostat 这个命令。你可能指的是 iostat —— Linux 中用于分析块设备吞吐量与延迟的核心工具，属于 sysstat 软件包。
下面直接讲清楚怎么用 iostat 看真实吞吐和延迟：
看真实吞吐量（IOPS 和 MB/s）
- 必须加
-x选项：iostat -x 1（每秒刷新一次扩展统计） - 关键字段：
-
r_ios/w_ios：每秒真正下发到设备的读/写请求数 → 这才是真实 IOPS -
rMB/s/wMB/s：每秒实际落盘的读/写数据量（MB），绕过 page cache，可对标厂商标称值
-
- 别依赖
r/s、w/s或rkB/s、wkB/s：它们受请求合并、缓存、虚拟层干扰，容易高估或失真
看延迟（await、r_await、w_await）
-
await：平均每次 I/O 请求从发出到完成的总耗时（毫秒），含排队 + 服务时间- HDD 超过 10–15ms、SSD 超过 2–5ms、NVMe 超过 0.2ms 就需警惕
-
r_await和w_await：分别看读/写路径延迟，若差异大，说明某类操作路径异常（如日志写阻塞、ext4 journal 延迟等）
快速判断瓶颈类型
-
await高 +%util高 +r_ios/w_ios低 → 物理磁盘响应慢（机械盘老化、SSD 写放大、RAID卡缓存失效） -
await高 +%util低 → 请求卡在内核层（block queue 拥塞、文件系统锁、journal 延迟），不是磁盘本身问题 -
await正常但业务慢 → 可能是应用层同步等待、小 IO 频繁、或未使用 direct I/O 导致缓存误导
辅助验证技巧
- 查队列长度：
avgqu-sz > 1且持续上升，说明请求积压在内核队列 - 看请求大小：
avgrq-sz × 512 ≈ rMB/s × 1024 / r_ios，不匹配则存在压缩、协议开销或重定向 - 结合
iotop -oP或pidstat -d 1定位具体刷盘进程
不复杂但容易忽略。
