iostat -x 是唯一能看真实 IOPS 的命令，其 r_ios 和 w_ios 字段反映真正下发到设备的每秒读写请求数，而普通 iostat 的 r/s、w/s 是上层合并后的逻辑值，易失真。
iostat -x 是唯一能看真实 IOPS 的命令
普通 iostat 显示的 r/s 和 w/s 不是真实 IOPS，它们是上层 IO 栈合并、重排后的逻辑请求数，在带缓存、virtio、多路径或 NVMe 队列的环境里严重失真。只有加 -x 选项后输出的 r_ios（读 I/O 次数）和 w_ios（写 I/O 次数）才代表真正下发到设备或 virtio queue 的请求个数。
执行以下命令即可获得每秒真实读写次数：
iostat -dx 1 3
重点关注字段：
-
r_ios和w_ios：单位是次/秒，即真实读/写 IOPS -
rMB/s和wMB/s：绕过 page cache 的真实吞吐，单位 MB/s -
%util：仅对传统 HDD 有参考价值；NVMe 多队列下接近 100% 并不意味着瓶颈 -
await：平均等待毫秒，若持续 >10ms 且%util高，说明队列积压而非磁盘本身慢
为什么 dd 测不出 IOPS，只能测吞吐
dd 命令本质是单线程顺序拷贝，它反映的是大块连续 IO 下的吞吐能力（如 bs=1M），但完全无法模拟随机小 IO 场景，也无法体现并发请求数——而 IOPS 正是为衡量后者设计的。
常见误用：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用
dd if=/dev/zero of=test bs=4k count=100000算“4K 随机写 IOPS”：错，这是顺序写，且未绕过缓存 - 看
dd输出的123 MB/s就认为 IOPS 很高：吞吐高 ≠ IOPS 高，比如 123 MB/s ÷ 4 KB = ~31.5K IOPS，但实际dd根本没发出那么多请求 - 忽略
iflag=direct oflag=direct：不加这个，数据走 page cache，测的是内存速度，不是磁盘真实 IOPS
定位高 IOPS 来源必须配合 iotop 或 pidstat
iostat -x 只告诉你“设备忙”，不告诉你“谁在刷盘”。当 r_ios 或 w_ios 异常飙升时，需立刻查进程：
- 实时查看 TOP IO 进程：
sudo iotop -oP（只显示实际在做 IO 的进程，-P 表示忽略线程） - 按秒采样并统计：
pidstat -d 1，关注rkB/s和wkB/s列，换算成 IOPS 要除以平均 IO 大小（如 4K → ÷4） - 注意：
iotop显示的 “DISK READ/WRITE” 是带缓存的速率，不能直接当 IOPS；它只是帮你快速锁定嫌疑进程
FIO 才是测可控 IOPS 的正确工具
如果要验证某块盘在特定负载下的稳定 IOPS（比如 4K 随机读 50K IOPS），iostat 是观测手段，fio 才是施压工具。它能精确控制 IO 类型、大小、队列深度、线程数。
例如测试裸设备 /dev/vdc 的 4K 随机读 IOPS：
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=4 --iodepth=128 --direct=1 --runtime=60 --time_based --filename=/dev/vdc --group_reporting
关键参数含义：
-
--rw=randread：随机读；换成randwrite测写 -
--bs=4k：每次 IO 大小为 4KB -
--iodepth=128：队列深度，直接影响并发 IOPS 上限 -
--direct=1：绕过 page cache，测真实块层性能 - 结果中
IOPS字段直接给出数值，lat (usec)给出延迟分布
别拿 FIO 测系统盘或挂载点——必须用裸设备（fdisk -l 和 blkid 确认无分区无文件系统），否则会损坏数据。
