云主机慢，先证明是不是磁盘慢：IOPS 的量级差与基线测法
一、”慢”要归因到磁盘，需要证据
社区那篇文章指出的现象确实普遍：采购云主机时对比的是核数、内存和带宽，磁盘只按容量选，最后按需买了一块普通云盘，业务上线后才发现慢。而慢的表现往往不像磁盘问题——CPU 空闲、内存充足、带宽没用满，接口却稳定地慢，高峰期还成倍恶化。这类项目在排障时最常见的做法是先怀疑网络，尤其是跨地域或境外节点访问，网络被反复排查一遍之后才回头测盘。
回头测的时候，两个指标足够作出初步判断。iostat -x 看磁盘侧：%util 长时间接近饱和说明队列在等，await 反映一次 IO 的平均等待时间，它的抬升比 CPU 曲线更能说明问题；vmstat 看系统侧：wa（IO 等待占比）持续偏高，且 r 队列不长，基本可以排除计算瓶颈。这两个读数配合”CPU 空闲但响应慢”，就构成了把嫌疑收敛到磁盘的证据链起点。
需要提醒的是，%util 对并发设备并不总是可靠的饱和度指标（多队列设备可以同时服务多个请求）。所以它只用来做初判，结论要靠后面的基线测试。
二、三档介质之间是断层，不是台阶
差距必须写成数量级才不容易被误读。下面这张表刻意不给精确数字，因为各家云厂商的规格和限速策略都在变，但相对量级关系是稳定的。
| 介质 | 随机 IOPS 量级 | 典型延迟量级 | 适合什么 | 不适合什么 |
|---|---|---|---|---|
| 机械盘 HDD | 百量级 | 毫秒级 | 冷数据、备份、大文件顺序读写 | 任何有小文件随机读的业务 |
| SATA SSD | 万量级 | 百微秒级 | 常规 Web 与 CMS、中小数据库 | 高并发写入、大量小文件检索 |
| NVMe SSD | 十万量级 | 十微秒级 | 数据库、高并发动态页、索引类负载 | 只按容量需求买的低成本场景 |
从百到万再到十万，跨的是两个数量级，不是两档价格。这个关系的实际含义是：如果业务真的卡在随机 IO 上，同档位的调优（加缓存、改配置、换文件系统参数）通常只能改善百分之几十，而换介质改善的是十倍量级。反过来，如果业务根本没到盘的随机 IO 上限，升级到 NVMe 的收益会小到测不出来——这正是必须先测基线的原因。
三、为什么小文件随机读写才暴露差距
大文件顺序读写考验的是带宽，机械盘在这项上并不丢人，顺序吞吐可以接近甚至达到很多 SSD 的水位，所以只看”拷文件快不快”永远看不出问题。随机小 IO 考验的是寻道与并发：一次请求要定位、排队、等待，机械盘的寻道时间在毫秒级，IOPS 天花板就自然压在百的量级；固态没有寻道，限制来自协议栈与队列深度，NVMe 的多队列又能把并发上限推得更高。
三类负载在这上面最容易出问题：数据库的页读取天然以小随机读为主，索引未命中时更明显；CMS 与动态页表面看是网络服务，实际每页要读模板、配置、语言包、缓存分片等大量小文件，高并发下就是密集的随机读；日志写入看着是顺序写，但按小时切分、多服务并发写同一块盘时，会退化成带锁竞争的随机写。这也是为什么”业务量不大但页面首字慢”经常不是代码问题。
四、基线怎么打，以及规格封顶这个坑
fio 的基线要贴近业务的 IO 画像，而不是跑一个默认参数。我们的最小集合是四步：
- 清掉页缓存或直接用
--direct=1绕过缓存，否则测到的是内存不是盘。 - 4K 随机读，
iodepth从 1 起步，记录单队列深度下的 IOPS 与延迟——这一组最接近数据库慢查询时的真实体感。 - 同一参数下把
iodepth拉到 32、64，再看numjobs从 1 到 4、8，观察 IOPS 增长在哪一档开始变平。变平的位置就是这块盘（或这个实例）的并发上限。 - 补一组顺序读与 4K 随机写，写入侧对数据库和日志场景更敏感。
拿到基线后还有一件事要确认：云盘的性能会被实例规格封顶。同一块盘挂到不同核数、不同存储带宽的实例上，测出来的 IOPS 和吞吐可以差出一截——瓶颈在实例与存储之间的通道上，不在盘里。这解释了”换了更高级的盘却毫无改善”这类反馈：如果实例规格本来就限制住了通道上限，换盘只是换了个不会被用到的天花板。所以选型要成对看：盘的性能档位与实例规格的存储能力，取两者中较低的那个作为实际预期。
五、洹拓视角：三条务实建议与对应的验收标准
建议一：先测基线再升级。 任何磁盘相关的扩容申请，附上 iostat -x 的持续采样与 fio 四组结果。判断标准是明确的——如果基线里 %util 和 await 都没有抬升，或者 IOPS 远低于当前盘上限，那么问题不在盘，升级预算应该转给应用层（缓存、慢查询、批量写）。
建议二：不把 IO 密集型和日志型业务放同一块盘。 这两类的 IO 画像正好冲突：一个要低延迟随机读，一个要持续写入。混在一起的典型结果是写入高峰期间数据库延迟抖动，而监控面板上各项资源都不高。落地判据是分离之后复测同一组 fio 参数，随机读的 await 波动范围应明显收窄；如果没变化，说明瓶颈其实在实例规格上限，换盘布局是无效动作。
建议三：按随机 IOPS 需求选盘，而不是按容量。 容量决定单价，随机 IOPS 决定体验。估算法很直接：把业务峰值每秒的查询数、页面渲染次数、写入条数换算成每秒 IO 请求数，与基线测出的盘上限对比，留出一个缓冲系数。验收标准写成三句话就能检查——升级前后同参数基线数据齐备；实际业务的 await 落在业务方给出的上限之内；实例规格的存储能力不低于所选盘的标称档位。三条缺一，就不要在工单里写”性能问题已解决”。
对中小企业来说，这套流程的最大收益不是省下一块盘的钱，而是把”慢”从一句感受变成三个数字。有了数字，排障顺序、升级预算和验收责任才都有依据。
新乡洹拓科技有限公司，软件开发 · AI 大模型应用 · 云服务与部署运维。
咨询热线：400-829-9957
地址：河南省新乡市辉县市金城百货四楼