应用变慢时，磁盘不一定是元凶。要做云主机磁盘IO性能瓶颈分析，先把业务延迟与主机、云盘指标按同一时间段对照，再定位是哪类负载或限制造成影响。以下步骤适用于常见 Linux 云主机；不同云平台的监控名称和指标口径可能不同。
先确认慢在哪里
记录故障开始和结束时间，以及受影响的业务、进程和操作。查看应用响应时间、错误日志，同时观察 CPU、内存和磁盘指标。若只有某个应用变慢，其他磁盘读写正常，应先检查应用自身、锁等待或数据库查询；若多个进程同时出现读写延迟，再重点排查云盘。
检查挂载与空间：运行 lsblk、df -h 和 df -i。磁盘空间或 inode 接近耗尽时，写入和文件创建可能失败，但这不等同于设备 IO 饱和。还要确认业务数据实际位于哪个挂载点，避免监控了系统盘却漏掉数据盘。
用系统工具观察 IO
看延迟、队列和繁忙度
安装了 sysstat 的 Linux 系统可运行 iostat -xz 1 10，连续观察约 10 秒。重点看设备对应的 await（请求排队与处理的平均时间）、aqu-sz（平均队列长度）和 %util（设备忙碌时间比例）。短时尖峰可能是正常突发；应比较故障期间与平稳时段，而不是只凭一次采样判断。
这些字段需结合设备类型和工作负载解读：%util 长时间接近 100%、队列持续增长且 await 同时升高，才更支持 IO 受压的判断。对可并行处理请求的云盘，%util 并非单独可靠的饱和度结论。iostat 未安装时，可使用 vmstat 1 10 查看等待 IO 的任务与系统状态；它只能辅助判断，不能代替设备级指标。
找出产生读写的进程
运行 pidstat -d 1 10（部分系统需安装 sysstat），观察进程的读写速率。若没有该命令，可用 iotop（需安装，通常需要管理员权限）。将进程、设备和业务日志的时间对齐：持续写日志、数据库检查点、批量导入或备份，都可能造成阶段性负载；不要仅凭进程名认定它是异常源头。
对照云盘规格与监控
在云平台监控中查看盘的读写 IOPS、吞吐量、延迟和突发额度（若该产品提供），并核对云盘类型、容量及实例侧带宽上限。IOPS 是每秒操作次数，吞吐量是每秒传输的数据量：大量小块随机读写可能先碰到 IOPS 限制，连续大文件读写则可能先碰到吞吐量限制。不同规格和产品的上限不同，应以该云盘对应的控制台说明为准，不要套用统一数值。
若主机内 iostat 显示设备繁忙，但云盘监控未同步升高，检查监控时间粒度、盘符对应关系及实例侧限制；若平台指标显示限速或突发额度耗尽，则考虑调整云盘规格、扩容（部分产品扩容会影响性能上限）或错开批处理。扩规格前确认费用、变更流程和是否需要重启。
按风险顺序验证与处理
- 先采样：在问题发生时连续记录 iostat、pidstat 和业务延迟，至少覆盖一个完整的慢响应时段，并与正常时段比较。
- 再查限制：核对云盘指标、产品上限、突发额度、实例限制以及快照或备份任务是否重叠。
- 小范围复现：需要基准测试时，使用 fio 前先选非生产盘或专用测试文件，确认剩余空间和写入影响，并设置短时长、低并发。不要直接对承载数据的块设备运行写测试，以免覆盖数据。
- 逐项调整：先错开备份、降低不必要的并发或优化明显的读写模式；仍受规格限制时再评估升配。每次只改一项，并复测业务延迟及云盘指标。
完成云主机磁盘IO性能瓶颈分析，关键是让系统采样、云平台数据和业务现象互相印证。若证据只显示空间不足、单个进程异常或应用等待，就应针对该原因处理，而非直接换更高规格云盘。
常见问题
iowait 高就代表磁盘有问题吗？
不一定。它表示 CPU 有时间在等待 IO，但不能独立指出具体设备或根因，需结合设备延迟、队列和应用表现判断。
iostat 的 await 多高算异常？
没有适用于所有云盘和业务的统一阈值。应结合该设备平时水平、业务延迟目标和故障时的持续变化判断。
可以直接用 fio 测生产盘吗？
不建议直接对生产块设备做写测试。写入可能破坏数据，也可能干扰业务；优先使用隔离的测试盘或经评估的测试文件。