Linux怎么查看具体的IOPS峰值数据

要抓到真实的 IOPS 峰值，真正管用的其实是 iostat -dx 1。原因很直接：它按秒刷新，直接给出 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
• 混淆线程和进程：Ja va 进程常有多个 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，查询是随机读，归档是大块顺序写——混搭测试比单一模式更接近真实峰值场景。