iostat -x 输出的 r_ios/w_ios 就是真实 iops，它们是由块设备驱动或 virtio 层上报的实际每秒读写请求数，而非上层合并后的逻辑值 r/s、w/s；r_ios 和 w_ios 单位为“次/秒”，是唯一能直接反映设备级真实 i/o 操作频次的字段。
iostat -x 输出的 r_ios/w_ios 就是真实 IOPS
Linux 下唯一能直接反映“每秒下发到设备的真实读写操作数”的字段，是 iostat -x 输出里的 r_ios 和 w_ios。它们不是上层合并后的逻辑请求（r/s、w/s），而是由块设备驱动或 virtio 层上报的实际 I/O 次数——这才是你真正要的 IOPS。
常见误区：r/s 看起来像 IOPS，但它在 NVMe、LVM、多路径或带 write-back cache 的 RAID 上会被大幅合并/延迟下发，数值可能只有真实 r_ios 的 1/10；rkB/s 是吞吐量，不是次数，不能直接除以块大小算 IOPS（除非你知道每个请求恰好是 4K 且无合并）。
-
iostat -dx 1：加-d去掉 CPU 行干扰，-x才有r_ios字段，1是采样间隔（太长会漏尖峰，太短如0.1易刷屏且内核压力大） - 首次输出是自系统启动以来的平均值，忽略它；从第二行开始才是实时瞬时值
- 若只关心某盘（如
/dev/nvme0n1），直接iostat -dx 1 /dev/nvme0n1，避免被其他空闲设备稀释峰值 - 注意单位：
r_ios和w_ios后面没单位，但含义就是 “次/秒”
怎么抓到那个“最高的一秒”峰值？
峰值是瞬时跳变值，不是平均值。靠肉眼盯 iostat -dx 1 滚动输出容易错过，必须用脚本捕获极值：
执行以下命令可连续采样 60 秒，并记录 r_ios 最高值：
宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。
iostat -dx 1 60 | awk '$1 ~ /^\/dev\// {if ($3 > max) max = $3} END {print "max r_ios:", max}'
说明：
-
$1 ~ /^\/dev\//过滤出设备行（跳过标题和空行） -
$3对应r_ios列（不同内核版本列序可能微调，先跑一次iostat -dx 1 2确认位置） - 别用
watch或手动截图——人眼反应跟不上毫秒级尖峰 - 如果目标是写 IOPS，把
$3换成$4（w_ios通常在第 4 列）
为什么 pidstat -d 不能直接看 IOPS？
pidstat -d 1 只给进程级的 rkB/s 和 wkB/s，没有请求次数。它没法告诉你“这个进程发了多少个 4K 请求”，只能告诉你“它读了多大流量”。想从 pidstat 推 IOPS，得额外知道该进程的平均 IO 大小：
- 先用
pidstat -d 1找出 rkB/s 飙高的 PID - 再用
iostat -dx 1看对应设备的avgrq-sz（平均请求扇区数），换算：IOPS ≈ (rkB/s × 1024) ÷ (avgrq-sz × 512) - 但
avgrq-sz是设备全局均值，单个进程的 IO 模式（如 MySQL 随机读 vs rsync 顺序拷贝）可能差异极大，所以这个换算只是粗略估计 - 真正精准定位高 IOPS 进程，还是得靠
iotop -oP（只显示实际在做 IO 的进程）配合业务逻辑判断
别把 dd 或 fio 的结果当成“系统当前 IOPS 峰值”
dd 测的是单线程顺序吞吐，fio 是主动施压工具——它们测的是“这块盘能扛多少”，不是“现在系统正在跑多少”。你在生产环境看到的 IOPS 峰值，往往来自数据库随机查询、日志轮转、备份脚本批量读取等不可控组合。
-
dd if=/dev/zero of=test bs=4k count=100000：这是顺序写，r/s几乎为 0，w_ios可能很低，但wkB/s很高——它根本不是 IOPS 场景 -
fio脚本里设rw=randread+bs=4k+iodepth=64，才能模拟高 IOPS 负载，但这是人为造峰，不是观测 - 真实峰值常伴随高
r_await（>20ms）和高%util（>90%），这时r_ios冲高不是能力体现，而是队列积压信号
真正难的不是看到数字，而是判断这个峰值是健康波动、配置不当，还是介质开始退化——得结合 smartctl -a /dev/sdX 和历史趋势一起看。
