iostat -dx 1 是唯一能抓到真实 IOPS 秒级峰值的命令，因其 r_ios/w_ios 字段反映内核驱动直接上报的真实每秒读写次数，采样间隔为1秒可捕获瞬时尖峰，而默认 iostat 的 r/s、w/s 受 page cache 和 IO 合并干扰严重失真。
iostat -dx 1是唯一能抓到真实 IOPS 秒级峰值的命令，其他工具要么失真、要么不带时间粒度。
为什么必须用 iostat -dx 1 而不是 iostat 默认输出
默认 iostat 显示的 r/s 和 w/s 是上层 IO 栈合并后的逻辑请求数，在有 page cache、virtio、NVMe 多队列或 LVM 的环境里完全不可信。只有加 -x 后的 r_ios 和 w_ios 字段，才是内核驱动直接上报的、真正下发到设备的每秒读写次数——也就是真实 IOPS。
采样间隔设为 1 是关键：设成 5 或更大，会漏掉瞬时尖峰；设成 0.1 则刷屏且无意义，终端响应都跟不上。
- 别用
iostat -d：它不显示r_ios/w_ios，只输出旧式r/s - 别信
vmstat的bi/bo：单位是“块/秒”，未归一化，且不区分读写请求次数 -
sar -d可看历史，但实时峰值捕捉能力弱于iostat -dx 1
iostat -dx 1 输出里哪些字段对应秒级峰值
滚动观察时，紧盯以下三列的跳动最大值：
-
r_ios：每秒真实读 I/O 次数（单位：次/秒） -
w_ios：每秒真实写 I/O 次数（单位：次/秒） -
rMB/s和wMB/s：绕过 page cache 的真实吞吐（单位 MB/s），用于交叉验证——比如r_ios × 平均 IO 大小 ≈ rMB/s × 1024
注意 rkB/s 和 wkB/s 是旧单位，数值大但不直接对应 IOPS；%util 对 NVMe 盘基本失效，HDD 上接近 100% 也不等于 IOPS 到顶。
如何避免被干扰、精准聚焦目标盘
如果你只关心某块 SSD（比如 /dev/nvme0n1）或某个 LVM 逻辑卷（如 /dev/mapper/vg0-lv_root），不加过滤会被其他空闲盘的零值拉低注意力：
- 查单盘：
iostat -dx 1 /dev/nvme0n1 - 查所有分区（含 LVM 子设备）：
iostat -dx 1 -p ALL - 排除 CPU 行干扰（纯磁盘视图）：
iostat -dx 1 -d
不要依赖 iotop 或 dstat 看峰值：前者显示的是带缓存的速率，后者 --disk-tps 底层仍调用失真的 r/s，都不是真实下发到设备的 IOPS。
峰值出现时，怎么快速定位是哪个进程干的
iostat 告诉你“哪块盘在飙”，但不告诉你“谁干的”。这时必须切进程维度：
- 用
pidstat -d 1实时盯rkB/s和wkB/s：哪个 PID 的值突然冲到几百 KB/s 以上，基本就是源头（再除以平均 IO 大小，比如 4K，就能估算出该进程贡献的 IOPS） - 别用
pidstat -d 0：内核疯狂上报，终端卡死甚至触发 OOM - 精准指定进程：
pidstat -d 1 -p "$(pgrep -f 'redis-server')"，比ps aux | grep抗干扰强得多 - 按
p键切换线程视图，避免把一个 Java 进程的多个 GC 线程当成多个高读来源
真实场景中，IOPS 峰值往往伴随 r_await > 20ms 和 avgqu-sz 突增——这说明不是磁盘快慢问题，而是小 IO 随机打满队列深度，此时看进程比看硬件参数更有效。
