iostat -dx 1 是唯一能抓到真实 IOPS 峰值的命令，因其每秒刷新、直接输出 r_ios/w_ios（设备级真实读写请求数），而默认 iostat 的 r/s、w/s 在 NVMe/LVM/RAID 环境下严重失真；配合 pidstat -d 1 可定位高 IOPS 进程。
iostat -dx 1 是唯一能抓到真实 IOPS 峰值的命令
Linux 没有“历史峰值”数据库，IOPS 峰值是瞬时现象，必须靠高频采样捕获。iostat -dx 1 是最轻量、最可靠的方式——它每秒刷新一次，r_ios 和 w_ios 字段直接反映设备实际收到的读/写请求数（单位：次/秒），这才是真实 IOPS。
别用默认 iostat：它输出的 r/s 和 w/s 是上层合并后的逻辑请求，在 NVMe、LVM、RAID 或 virtio 环境下严重失真；不加 -x 就看不到 r_ios/w_ios；不加 -d 会混入 CPU 行干扰判断。
-
iostat -dx 1 /dev/nvme0n1：聚焦单块 NVMe 盘，避免被其他空闲设备稀释数值 -
iostat -dx 1 -p ALL：想看 LVM 逻辑卷或分区拆分数据时加这个 - 采样间隔别设成
0.1：刷屏快、无意义，内核上报频率也跟不上；1是平衡精度与可用性的底线 - 运行至少 30 秒：短于这个时间容易漏掉业务毛刺，尤其对周期性批量任务
pidstat -d 1 才能定位谁在制造 IOPS 峰值
iostat 告诉你“哪块盘在飙”，但 pidstat -d 1 才告诉你“谁干的”。它的 rkB/s 和 wkB/s 是真实瞬时速率（KB/s），不是累计值——盯着滚动输出，哪个 PID 的数值突然跳到几百或几千，基本就是源头。
常见坑：
- 不带采样间隔：
pidstat -d执行完就退出，根本看不到峰值变化 - 用
pidstat -d 0：内核疯狂上报，终端卡死，甚至触发 OOM - 权限问题：非 root 用户无法看到其他用户进程的 IO 数据，必须用
sudo pidstat -d 1 - 混淆线程和进程：Java 进程常有多个 GC 线程，按快捷键
p切换视图，避免误判 - 精准过滤：
pidstat -d 1 -p "$(pgrep -f 'postgres')"比ps aux | grep抗干扰强得多
为什么 iotop -o 容易错过真实 IOPS 峰值
iotop -o 界面友好，但和“峰值观测”天然冲突：它每秒刷新一次，而一次典型高 IOPS 操作（比如 mmap + readahead）可能只持续几十毫秒——大概率刚好错过。
更麻烦的是权限逻辑：iotop 非 root 运行时会静默跳过所有用户进程的 IO 数据，只显示内核线程（如 kswapd），看起来一片空白，误以为没压力。
- 必须用
sudo iotop -oP：-o 只显示活跃 IO 进程，-P 忽略线程，减少干扰 - 它显示的 “DISK READ/WRITE” 是带 page cache 的速率，不能直接当 IOPS 用——只是帮你快速圈定嫌疑进程
- 如果
iotop显示某进程 IO 很高，但pidstat -d 1里没对应 PID，说明该进程用了 direct I/O 或绕过了 VFS 层
fio 才是验证 IOPS 峰值能力的唯一手段
iostat 和 pidstat 是观测工具，只能告诉你“现在发生了什么”；要确认磁盘能否稳定扛住某个 IOPS 峰值（比如 4K 随机读 80K IOPS），必须用 fio 主动施压。
关键参数不能错：
-
--direct=1：绕过 page cache，测的是真实磁盘能力 -
--bs=4k：小块 IO 才体现随机访问 IOPS，bs=1M测的是吞吐不是 IOPS -
--iodepth=128：队列深度要足够，否则压不出峰值（SSD 通常需 32~256） -
--numjobs=4：多线程并发，模拟真实业务负载 -
--runtime=60：跑够 1 分钟，排除冷盘效应和瞬时抖动干扰
真正难的是把业务 IO 模式翻译成 fio 参数：比如数据库日志写是顺序小 IO，查询是随机读，归档是大块顺序写——混搭测试比单一模式更接近真实峰值场景。
