iostat -x 输出的 r_ios 和 w_ios 才是真实读/写 iops，因它们由驱动层直接上报，反映真正下发到设备的请求次数；而普通 iostat 的 r/s、w/s 是上层合并后的逻辑值，在 nvme、lvm 等环境中严重失真。

iostat -x 输出的 r_ios 和 w_ios 就是你要的真实读/写 IOPS，其他字段（如 r/s、w/s）在现代存储栈里基本不可信。

为什么必须用 iostat -dx 而不是普通 iostat

普通 iostat 显示的 r/s 和 w/s 是上层 IO 栈（VFS、block layer）合并后的逻辑请求数。在 NVMe、LVM、多路径或带 write-back cache 的 RAID 上，10 个应用发的小请求可能被合并成 1 个下发，r/s 就变成 1 —— 它根本不是设备真实承受的负载。

iostat -x 的 r_ios 和 w_ios 字段由块设备驱动或 virtio 层直接上报，代表真正发到物理设备或队列的请求数，单位就是“次/秒”。这才是你该盯的 IOPS。

• 执行 iostat -dx 1：加 -d 去掉 CPU 行干扰，-x 才有 r_ios/w_ios，1 是采样间隔（太长漏尖峰，太短如 0.1 秒易刷屏且内核压力大）
• 首次输出是系统启动以来的平均值，忽略它；从第二行开始才是实时瞬时值
• 若只关心某盘（如 /dev/nvme0n1），直接加设备路径：iostat -dx 1 /dev/nvme0n1，避免被空闲设备稀释峰值

怎么抓到那个“最高的一秒”IOPS 峰值

靠人眼盯 iostat -dx 1 滚动输出，大概率错过毫秒级尖峰。必须用脚本捕获极值：

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 确认位置（常见是第 3 列读、第 4 列写）
• 要抓写 IOPS 峰值？把 $3 换成 $4
• 别用 watch 或手动截图——反应速度跟不上，数据就丢了

为什么 pidstat -d 和 iotop 不能直接看 IOPS

pidstat -d 1 只给进程级的 rkB/s 和 wkB/s，没有请求次数。它没法告诉你“MySQL 发了多少个 4K 请求”，只能告诉你“它读了多大流量”。

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

想从 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 备份顺序）可能完全不同，这个换算只是粗略估计。

常见误判：高 IOPS 但业务不卡，或卡了却看不到高 IOPS

高 r_ios + 低 rkB/s → 小块随机读（比如数据库索引扫描），avgrq-sz 接近 8（即 4KB）；

高 r_ios + 高 await + 高 %util → 不是磁盘慢，而是队列积压或介质响应能力见顶（尤其 NVMe 多队列下 %util 接近 100% 很常见）；

业务卡顿但 r_ios 平平 → 可能是延迟毛刺（await 瞬间飙到 50ms+）、单次大 IO（avgrq-sz > 1024）、或 IO 被调度器压制（cat /proc/diskstats 查 io_ticks 和 time_in_queue）。

真实 IOPS 必须结合 r_ios/w_ios、await、avgrq-sz 三者交叉验证，单独看任一字段都容易误判。