Linux怎么查看控制器支持的最高IOPS

想直接查控制器“支持的最高IOPS”？这其实是个伪命题。因为IOPS并非一个固定的硬件上限，而是由负载、队列深度、IO大小等动态因素共同决定的理论估算值。要准确推算，必须结合 lspci 查PCIe带宽、nvme id-ctrl 查协议版本与MDTS，以及 nvme id-ns 查命名空间参数进行综合评估。需要注意的是，iostat 显示的是实际下发的IOPS，而非硬件的理论极限。

Linux无法直接查控制器“支持的最高IOPS”

控制器本身并不会对外直接给出“理论最大 IOPS”这个数字。Linux 内核以及用户态工具，比如 iostat、lshw、lspci，能展示的更多是运行时的实际表现，或者硬件规格层面的描述，但它们不会明确告诉你“这颗 NVMe 控制器最多能跑多少 IOPS”。说到底，所谓“最高 IOPS”并不是某个写死在寄存器里的固定参数，而是一个动态结果：负载类型、队列深度、IO 大小、协议开销、固件策略，都会一起影响最终表现。

看 PCIe 通道数和 NVMe 协议版本能估算理论上限

真正可查、且对 IOPS 有硬性约束的是物理层能力。你需要组合查以下三项：

• lspci -vv -s $(lspci | grep -i nvme | head -n1 | awk '{print $1}') | grep -E "(LnkCap|LnkSta)" —— 看 LnkCap 中的 Speed（如 8.0 GT/s）和 Width（如 x4），这是 PCIe 带宽天花板
• sudo nvme id-ctrl /dev/nvme0n1 | grep -i "ver|mdts" —— 查 ver 字段确认 NVMe 协议版本（1.2/1.3/1.4/2.0），版本越高，命令处理效率和队列管理越强；mdts 是最大数据传输大小（单位为 2^mdts × 512B），影响单次 IO 上限
• sudo nvme id-ns /dev/nvme0n1 | grep -i "npwg|npwa|nacwu" —— 这些是命名空间级的写入粒度与对齐要求，间接限制小 IO 效率

例如：PCIe 4.0 x4 + NVMe 1.4 + 支持 64K 最大队列深度的盘，4K 随机读理论峰值常被厂商标为 700K~1M IOPS —— 但这只是参考值，实际受驱动、内核 IO 调度、libaio 配置等层层压制。

iostat -x 显示的是真实下发值，不是控制器上限

很多人误把 iostat -x 的 r_ios/w_ios 当成“控制器能力”，其实它只是告诉你“过去一秒里，设备驱动向控制器发了多少个请求”。它可能远低于上限（比如业务没压满），也可能因队列拥塞而卡在低位（await > 20ms 且 avgqu-sz 持续 > 32）。关键区别在于：

• r_ios 是观测结果，不是规格参数
• 如果 %util 长期 < 80% 但 r_ios 已到 300K，说明瓶颈不在控制器，而在上层（如文件系统锁、page cache 回写策略、应用线程数不足）
• 若 avgqu-sz 接近 nvme id-ctrl 报出的 nn（Number of Namespaces）× mqes（Maximum Queue Entries Supported），才说明控制器队列真被填满了

真要测出控制器逼近极限的 IOPS，只能靠 fio 施压

没有“查看”命令，只有“打出来”。用 fio 逼近控制器能力需满足三个条件：

• 绕过所有缓存：direct=1 + invalidate=1
• 榨干队列深度：iodepth=256 或更高（需先查 nvme id-ctrl 的 mqes 值）
• 用足够并发任务模拟真实压力：numjobs=16 或 32，避免单线程成为瓶颈

典型命令：
fio --name=test --ioengine=libaio --rw=randread --bs=4k --iodepth=256 --numjobs=32 --direct=1 --invalidate=1 --runtime=30 --time_based --filename=/dev/nvme0n1 --group_reporting
注意：此操作会极大占用设备，务必在维护窗口执行，且不能在生产数据盘上直接跑裸设备测试。

最易被忽略的一点：NVMe 控制器的“最高 IOPS”永远依赖于具体 workload —— 同一块盘，4K 随机读能到 800K，4K 随机写可能只有 200K，而 128K 顺序读又会掉到 100K。别信单一数字，要看你的真实 IO 模式。