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：说明队列已满但请求发不出去，瓶颈不在设备本身，而在并发控制或调度 a vgrq-sz长期低于 8（即平均请求 < 4KB）：大概率是小 IO 场景，此时 IOPS 上限取决于延迟和队列深度，而非吞吐带宽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 的结果看，关键得先确认，测到的到底是哪一层。
