磁盘变慢，不一定是磁盘规格不足：也可能是突发额度耗尽、读写模式改变，或应用在等待同步写入。做好云主机磁盘IO性能优化，建议先测清瓶颈，再逐项调整，并用相同负载验证效果。
第一步：先看监控，确认慢在哪里
在云平台控制台查看磁盘的读写吞吐量、IOPS和延迟，并与业务变慢的时间段对照。不同平台的指标名称和采样间隔可能不同；若磁盘有突发性能或额度机制，还要检查额度是否持续耗用或已受限。
进入系统后，可用 iostat -x 1 连续观察设备指标，用 pidstat -d 1 查看进程读写情况。重点看读写请求大小、队列长度和延迟是否在业务高峰同步上升。%util 接近满载可作为线索，但对可并行处理请求的设备，不能单独据此判定磁盘已饱和。
第二步：建立可比较的基线
先记录当前业务的读写比例、平均请求大小、并发量和繁忙时段表现。随机小块读写与顺序大块读写对磁盘的要求不同，单看总吞吐量可能掩盖问题。若要做对照测试，可用 fio 在专用测试文件上模拟接近业务的负载；例如设置 4 KiB 随机读、队列深度 16、运行 60 秒，观察延迟和 IOPS。这个组合仅是测试示例，不代表适合所有应用。
测试前确认文件系统有足够空间，并避开生产高峰。不要直接对承载业务数据的裸设备做写入测试；这可能破坏数据。云主机磁盘IO性能优化的判断，应以相同测试条件下的变化为准，而不是只比较不同时间的单次读数。
第三步：找到产生IO的进程和操作
把系统指标与应用行为对应起来：检查备份、日志轮转、批量导入、缓存淘汰等任务是否恰好与延迟升高重合。若只有写延迟升高，优先查同步写入、频繁刷盘和小块随机写；读延迟升高，则留意重复扫描、缓存命中率下降或并发读取集中。
还要核对挂载点和设备映射，避免把系统盘、数据盘或临时盘的指标混在一起。先确认问题落在哪个卷，再决定调整应用、文件系统还是云盘规格。
第四步：按瓶颈调整，不要一次改多项
- IOPS不足：如果请求以小块随机读写为主，比较云盘档位的IOPS上限和当前负载。提高规格通常会增加费用，也可能受实例侧带宽或IOPS上限约束。
- 吞吐量不足：顺序读写大文件时，核对磁盘与实例的吞吐上限；如果其中一侧已到上限，升级另一侧未必有效。
- 延迟不稳：检查突发额度、邻近任务和队列积压。可以调整备份或批处理时段，也可评估更稳定的磁盘类型，但需结合持续负载和成本。
- 队列参数不合适：只有确认队列积压与应用并发有关后，才尝试调整并发或队列深度。增大队列可能提高吞吐，也可能让单个请求等待更久；先在测试环境小幅修改并记录原值。
第五步：复测并保留回退方案
一次只改一个因素，例如先调磁盘规格，或单独调整应用并发。随后用相同的 fio 参数或业务压测复测，并在相同观察时段比较延迟、IOPS、吞吐量及错误情况。若吞吐上升但尾部延迟变差，或业务耗时没有改善，就不能只凭单一指标认定调整成功。
记录修改前后的配置、测试条件和监控截图，确认业务稳定后再扩大变更范围。若结果变差，按记录恢复配置。这样，云主机磁盘IO性能优化就形成了“监控—定位—调整—验证”的闭环，而不是反复盲目加盘。
常见问题
只要 %util 达到 100%，就必须升级磁盘吗？
不一定。结合延迟、队列、实际业务耗时及云平台限额一起判断；并行设备的利用率数值也不等同于简单的单队列饱和。
云盘规格升高后，性能一定会提升吗？
不一定。实例本身可能有IOPS或吞吐限制，应用也可能受CPU、内存或锁等待影响。先确认瓶颈位置，再比较升级成本与收益。
能否在生产环境直接跑 fio？
应谨慎。测试会产生额外负载；写测试尤其要使用专用测试文件，并选择低峰时段。对关键业务，优先在隔离环境验证参数。
多久复查一次磁盘指标？
没有适用于所有业务的固定周期。发布、备份或负载模式变化后应重点复查，并保留日常趋势，以便识别持续变化与短时尖峰。