TG咨询提高NVMe本地盘IOPS，首先要确认目标是数据库事务、虚拟机存储、编译缓存，还是日志写入。不同负载对延迟、并发和写入稳定性的要求不同。单纯追求测试软件里的峰值，往往会把时间花在无效调整上。
真正有价值的NVMe本地盘IOPS优化，应当围绕实际访问模式展开：请求大小、随机读写比例、并发数、数据集容量，以及盘在持续运行后的表现。下面这些常见做法，通常不能直接带来稳定收益。
只把队列深度调高，通常不是优化
队列深度越高，提交给设备的并发请求越多，跑分中的IOPS可能随之上升。但应用线程数、CPU调度、锁竞争和盘的内部并行度都有上限。队列深度从较低值提高到中等范围，可能有明显变化；继续增加后，常见结果是延迟变长，尾延迟更差，而业务吞吐几乎不再增加。
如何判断是否调过头
- 先根据真实业务记录请求大小、读写比例和并发线程数，不要直接套用跑分软件的最高配置。
- 分别测试低、中、高三档并发，记录平均延迟、P95或P99延迟和完成IOPS。
- 如果IOPS增长很小，但尾延迟持续上升，应回退队列深度，而不是继续加大。
例如在线事务系统更重视稳定响应，批量数据处理才可能适合较高并发。因此，队列深度不是越大越好。
只看顺序带宽，无法证明随机性能提升
厂商标称的顺序读取或写入带宽，主要反映大块连续访问。数据库索引、虚拟机磁盘和小文件扫描却常以随机读写为主。顺序带宽从约3GB/s提升到约7GB/s，并不意味着小请求IOPS会同比增长；接口代际、控制器缓存和访问延迟都可能成为限制。
进行NVMe本地盘IOPS优化时，应使用与业务相近的测试模型。测试至少要区分读取和写入、同步和异步、不同请求大小，并让数据集足够大，避免全部命中缓存。测试时还要保留预热阶段，否则刚开始的结果可能偏高。
关闭省电功能，不一定换来有效收益
部分系统会通过PCIe链路电源状态和NVMe电源状态降低空闲功耗。强行关闭省电功能，可能减少唤醒延迟，但在持续高负载场景中，收益通常有限，反而会增加空闲功耗和平台发热。若业务是间歇性访问，频繁唤醒带来的影响应单独测量，不能凭经验判断。
先确认设备是否运行在预期的PCIe链路宽度和速率，再比较省电设置开启、关闭时的业务延迟。若链路实际只协商到较低速率，优先检查插槽共享、固件设置和主板兼容性；这比盲目关闭电源管理更有针对性。
文件系统参数并非万能开关
使用noatime等挂载选项，可以减少部分文件访问时间更新，但它不会改变设备控制器的并行能力，也不能把低效的随机写入自动变成高效访问。关闭写入屏障或强制使用不符合数据保护要求的缓存策略，则可能带来断电丢数据风险，不应作为常规IOPS优化手段。
TRIM应按场景验证
TRIM有助于文件系统把已释放空间告知SSD，长期写入后可能改善回收效率。不过，定期执行TRIM并不等于即时提高每次测试的IOPS。应确认文件系统、内核和设备支持情况，并在业务低峰运行，避免把维护操作与在线负载叠加。
忽略温度和容量，短跑结果没有参考价值
NVMe盘在持续写入或高并发随机访问时可能触发热降速。刚启动几分钟的测试结果，不能代表连续运行数十分钟后的稳定水平。盘接近满载时，预留空间减少，后台垃圾回收也可能增加写入延迟；因此不能只依据空盘成绩选型。
更可靠的NVMe本地盘IOPS优化验证流程如下：
- 记录盘的固件版本、可用容量、PCIe链路状态和系统内核版本。
- 用接近真实数据集的容量进行预热，避免只测空盘或缓存。
- 分别测试短时峰值与持续负载，观察平均值和P99延迟。
- 重复测试至少数轮，确认结果是否受温度、后台任务或缓存影响。
- 将测试结果与业务指标对照；若IOPS提高但事务延迟没有改善，就不要把该调整视为成功。
应用访问模式往往比跑分参数更关键
如果程序频繁提交极小请求、每次都等待完成，设备再快也会受系统调用和同步等待限制。可以在不改变数据一致性要求的前提下，合并相邻请求、使用异步I/O，或调整线程模型。但这属于应用设计优化，必须通过功能和稳定性测试验证，不能简单套用。
总之，NVMe本地盘IOPS优化不是堆高队列深度、关闭省电或修改一个挂载参数。先还原业务负载，再检查链路、容量、温度和延迟分布，通常比追逐单项峰值更可靠。
常见问题
问：IOPS越高，应用一定越快吗？
不一定。应用可能受CPU、锁、网络、事务提交或尾延迟限制，峰值IOPS不能替代端到端响应时间。
问：是否应该把盘填满后测试？
不应只测满盘状态。应同时测试空盘、常用容量和接近实际占用率的状态，观察垃圾回收对性能的影响。
问：PCIe升级后IOPS一定翻倍吗？
不一定。若工作负载受延迟、软件并发或控制器能力限制，接口带宽提升不会等比例转化为IOPS。
问：如何选择测试工具参数？
以业务日志或监控数据为依据，匹配请求大小、读写比例、并发和持续时间，并同时记录延迟分位数。
