iostat -x 无法查控制器最大 iops，它只反映实时负载；r_ios/w_ios 是当前实际下发到设备的请求次数，非硬件上限，最大 iops 需通过 fio 压测结合厂商规格（如 pcie 通道数、队列深度）验证。

iostat -x 无法查控制器最大 IOPS，它只反映实时负载

iostat -x 输出的 r_ios/w_ios 是当前实际下发到设备（或 virtio queue）的请求次数，不是硬件能力上限。控制器最大 IOPS 是厂商在特定条件（如队列深度、IO大小、直通模式）下标称的理论值，Linux 内核不暴露该参数，也不存在通用 sysfs 或 ioctl 接口可直接读取。

查 NVMe 控制器最大 IOPS 要看型号规格和 PCIe 通道数

NVMe 控制器性能上限由三要素决定：主控芯片型号、PCIe 版本与通道数（x2/x4/x8）、固件支持的队列深度。例如：

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• lspci -vv -s $(lspci | grep -i nvme | head -1 | awk '{print $1}') | grep -A5 "LnkCap\|LnkSta" 查 PCIe 代数和宽度（如 LnkCap: Port #0, Speed 8.0GT/s, Width x4）
• sudo nvme id-ctrl /dev/nvme0n1 | grep -E "(mn|fr|sq)" 获取型号（mn）、固件版本（fr）、支持的最大 SQ/EQ 数（sq）
• 对照厂商文档（如 Samsung 980 Pro 标称随机读 600K IOPS @ QD32，Intel Optane P5800X 标称 1.2M IOPS @ QD256）——这些数值必须用 fio 在相同条件下实测验证，不能直接从系统读出

SATA/SAS 控制器最大 IOPS 基本取决于物理层协议限制

SATA III 单通道理论带宽 6 Gbps ≈ 600 MB/s，按 4K 随机 IO 算，理论上限约 150K IOPS（600×1024÷4），但实际受 AHCI 协议单队列、命令开销、机械盘寻道等制约，真实值远低于此。SAS-3（12 Gbps）理论更高，但同样受限于 HBA 芯片和驱动。关键点：

• lspci -d ::0106 -vv | grep -i "ahci\|sata\|sas" 确认控制器类型和链接状态
• cat /sys/class/scsi_host/host*/device/model 查 HBA 型号（如 LSI SAS3008），再查该芯片 datasheet 中的“max queue depth”和“IOPS spec”
• 注意：AHCI 模式下即使接 NVMe 盘（通过 PCIe-to-SATA 桥），也无法突破 AHCI 单队列瓶颈，iostat -x 显示的 r_ios 会严重低估真实能力

真正能逼近控制器极限的只有 fio + direct=1 + 高队列深度

Linux 下没有“查看最大 IOPS”的命令，只有“压测逼近最大 IOPS”的方法。必须绕过所有缓存和文件系统层，直接对裸设备施压：

• 确认设备是否支持直通：sudo blockdev --getro /dev/nvme0n1 应返回 0；sudo hdparm -I /dev/sda | grep -i "Native command queuing" 查 NCQ 支持
• 典型压测命令：fio --name=test --ioengine=libaio --rw=randread --bs=4k --direct=1 --iodepth=256 --numjobs=8 --runtime=120 --filename=/dev/nvme0n1 --group_reporting
• 结果中 IOPS=io_submit/io_complete 才是当前配置下该控制器+介质组合的实际峰值；反复调高 --iodepth 和 --numjobs 直到 IOPS 不再增长，即接近控制器瓶颈
• 容易被忽略的是：同一块盘在不同内核版本、nvme 驱动参数（如 nvme_core.default_ps_max_latency_us）、CPU 绑核策略下结果可能差 20% 以上