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-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
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% 以上
