Linux无固定磁盘最高IOPS值，该值由硬件、队列深度、IO调度等动态决定；iostat -dx 1的r_ios/w_ios仅反映实时下发请求数，非能力上限；高%util、高await、低r_ios表明瓶颈在并发控制或调度而非设备本身。
Linux本身不提供“磁盘支持的最高IOPS”这一静态指标——它不是写死在驱动或设备里的固定值，而是由硬件能力、队列深度、IO调度、并发模型和负载特征共同决定的动态上限。你无法用一个命令直接查出“这块盘最大能跑多少 IOPS”，只能通过实测逼近它。
iostat -x 只能看当前实际 IOPS，不能反映上限
iostat -dx 1 输出的 r_ios 和 w_ios 是“此刻真实下发到设备的请求数”，属于观测值，不是能力边界。即使显示 20K IOPS，也不能说明这已是极限；同样，若只看到 5K，也可能是业务没压上去，或被上层限制（如文件系统锁、进程串行 IO）卡住了。
- 高
%util+ 高await+ 低r_ios：说明队列已满但请求发不出去，瓶颈不在设备本身，而在并发控制或调度 -
avgrq-sz长期低于 8（即平均请求 -
rrqm/s或wrqm/s接近 0：意味着几乎没有请求合并，IO 是高度随机、不可聚合的，这种负载下设备更容易达到 IOPS 瓶颈
fio 是唯一能逼近“支持最高 IOPS”的工具
要摸清一块盘（尤其是 NVMe 或高性能 SSD）在特定 IO 模式下的理论上限，必须用 fio 主动施压，而不是被动观察。关键参数组合决定了你能打到多高：
-
--iodepth必须足够大（如 128 或 256），否则队列空转，压不出峰值 IOPS -
--numjobs要匹配 CPU 核心数和设备队列数；太少压不起来，太多反而引入调度开销 -
--bs=4k是测随机 IOPS 的标准块大小；换成 64k 就变成测吞吐，结果不可比 -
--direct=1强制绕过 page cache，否则测的是内存速度 - 测试目标必须是裸设备（如
/dev/nvme0n1）或独立分区，避免文件系统干扰
典型命令：fio --name=randread --ioengine=libaio --rw=randread --bs=4k --iodepth=256 --numjobs=8 --direct=1 --runtime=30 --filename=/dev/nvme0n1 --group_reporting
硬件规格与队列深度才是真正的天花板
所谓“支持的最高 IOPS”，最终受限于三件事：
- NVMe 设备的
MQ（多队列）数量和每个队列的深度（常为 64/128/256），可通过lspci -vv -s $(lspci | grep NVMe | awk '{print $1}') | grep -A 10 "Queue"查看 - SSD 控制器的并行通道数和 NAND 颗粒响应延迟；厂商标称的 “500K IOPS” 通常指 PCIe 5.0 x4 + 128 队列深度 + 4K 随机读的理想值
- Linux 内核的
blk-mq配置和/sys/block/nvme0n1/queue/nr_requests实际队列长度，这个值可能被 udev 规则或云平台虚拟化层（如 AWS EBS、阿里云云盘）人为限制
真正容易被忽略的是：同一块 NVMe 盘，在 KVM 虚拟机里跑出的最高 IOPS，往往只有物理机的 60%～80%，因为 virtio-blk 协议栈引入了额外延迟和队列截断；而容器或 Kubernetes 环境中若用了 overlayfs 或 hostPath 绑定，又会叠加一层文件系统开销。别只盯着 fio 结果，得确认你测的是哪一层。
