Linux怎么查看具体的IOPS峰值数据
要抓到真实的 IOPS 峰值,真正管用的其实是 iostat -dx 1。原因很直接:它按秒刷新,直接给出 r_ios/w_ios,也就是设备层面真实发生的读写请求数。相比之下,默认 iostat 展示的 r/s、w/s 在 NVMe、LVM、RAID 这类环境里往往会出现明显失真,参考价值并不高。
要抓到真实的 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,查询是随机读,归档是大块顺序写——混搭测试比单一模式更接近真实峰值场景。


































