云盘看起来没有跑满，应用却出现读写变慢，问题可能出在 IOPS 上限、实例存储带宽、设备队列或单个进程。排查 Linux云端实例磁盘IOPS监控与瓶颈定位，不宜只盯一个利用率数字。按“云盘指标—系统设备—进程—队列”逐层核对，才能缩小范围。
第一步：先看云平台上的云盘指标
在云平台监控页选择目标云盘，并把时间范围设为故障发生前后。重点对照读写 IOPS、读写吞吐量、平均时延，以及平台提供的突发额度或性能额度指标。不同平台的指标名称和采样周期并不完全相同，应以对应产品文档为准。
若 IOPS 长时间贴近云盘配置上限，同时时延上升，优先怀疑云盘性能规格不足；若吞吐量已接近上限，而 IOPS 尚有余量，可能是单次读写块较大。突发型云盘还要留意额度耗尽后的性能变化。不要仅凭某一分钟的峰值判断，宜对比数分钟至数十分钟的趋势，并确认实例自身是否另有存储带宽限制。
第二步：确认实例里的设备与整体负载
登录实例后，先用 lsblk 查看块设备及挂载关系，再运行 iostat -xz 1 10 观察设备指标。若系统没有 iostat，可在常见发行版中安装 sysstat 软件包。重点看 r/s、w/s、rkB/s、wkB/s、await、aqu-sz 和 %util；设备名称可结合 lsblk 与挂载点确认，避免把系统盘和数据盘看混。
%util 接近 100% 可作为繁忙线索，但在多队列设备上不能单独等同于“性能已耗尽”。应同时查看 await（平均等待时间）和 aqu-sz（平均队列长度），并与云平台时延、吞吐量趋势交叉验证。Linux云端实例磁盘IOPS监控与瓶颈定位，关键是多项指标同一时间出现一致变化。
第三步：把设备读写对应到进程
整体设备繁忙，不代表所有进程都在争用磁盘。用 pidstat -d 1 10 按进程观察读写速率；若已安装 sysstat，也可用 iotop -oPa 查看产生实际 I/O 的进程。执行 iotop 可能需要 root 权限，部分环境还需启用内核任务统计。
将进程输出与设备忙碌时段对齐：备份、日志轮转或批量导入可能形成短时写入峰值；数据库、容器运行时等则应进一步确认数据目录落在哪个块设备。进程读写量低但设备时延高时，也要考虑文件系统写回、其他容器或未被当前工具完整归因的内核 I/O。
第四步：核对队列与性能边界
如果云盘 IOPS 未达上限，但 iostat 显示等待和队列持续增加，应检查实例级存储带宽、磁盘共享或限速策略，以及文件系统和应用并发设置。若队列不高而应用仍慢，问题也可能在锁等待、内存回收或应用自身处理链路，不应直接扩容云盘。
- 记录故障时段的云盘 IOPS、吞吐量和时延，并核实配置上限及突发额度。
- 用 lsblk 确认设备映射，再连续采集 iostat 输出，比较正常与异常时段。
- 用 pidstat 或 iotop 找出主要 I/O 进程，核对其数据目录和业务任务。
- 根据证据调整云盘规格、实例规格或任务并发；变更后在相近负载下复查指标。
fio 可用于受控压测，但写测试会真实读写目标设备，可能覆盖数据或影响线上业务。只应在隔离测试盘上运行，先确认测试文件、块大小、读写比例和持续时间；不要直接对生产裸设备执行写入测试。
常见问题
IOPS 高就一定是瓶颈吗？
不一定。只有接近性能上限并伴随时延、队列或业务延迟升高时，才更像存储瓶颈；低时延下的高 IOPS 可能只是正常负载。
await 多高算异常？
没有适用于所有云盘和业务的统一阈值。应与该设备的历史基线、云平台时延及业务响应时间比较，并关注持续性变化。
先升云盘规格还是实例规格？
云盘指标触顶时优先评估云盘规格；实例存储带宽或实例级限制先触顶时，需评估实例规格。依据云平台指标与系统采样共同判断，避免盲目升级。
按四层证据逐步排查，比单看利用率更可靠。把云盘上限、设备等待、进程来源和队列变化放到同一时间线上，Linux云端实例磁盘IOPS监控与瓶颈定位才能落到具体原因和可验证的调整方案。
