云磁盘 io 性能问题多因配置或使用不当而非硬件故障，需结合厂商 io 模型分析，关注 iops/ 吞吐量前提条件、io 大小影响、iostat 关键指标、linux 层调度器与队列深度等限制，并通过 fio 分层压测定位瓶颈。
云磁盘 IO 性能问题通常不是磁盘本身坏了，而是配置、使用方式或负载模式与云平台特性不匹配。Linux 下需结合云厂商的 IO 模型（如 EBS 的 IOPS 限制、云硬盘的队列深度、突发性能桶等）来分析，不能套用本地 SSD 的经验。
看懂云磁盘的性能规格
不同云厂商对同一款云盘标注的“最大 IOPS”和“最大吞吐量”有前提条件：
- 是否开启 EBS 优化实例（AWS）或 高性能 IO 模式（阿里云 ESSD PL1/PL2）——未开启可能只有标称值的 30%~50%
- IOPS 是否受 基线 + 突发 机制限制（如 AWS gp3 默认 3000 IOPS 基线，可额外消耗 I /O Credits；阿里云 ESSD AutoPL 按实际负载动态升降）
- 单次 IO 大小影响显著：小 IO（4KB）吃 IOPS，大 IO（128KB+）吃吞吐量，云盘规格往往只保障其中一项达到上限
iostat 不是万能的，但要看对指标
iostat -x 1输出中，重点关注这几个字段而非 avgqu-sz 或 %util：
- r/s 和 w/s：实际每秒读写次数，对比云盘标称 IOPS（注意单位统一，有些厂商标的是“最大随机读 IOPS”，而你的业务可能是顺序写）
- rkB/s 和 wkB/s：换算成 MB/s，看是否接近吞吐上限（如 1000 MB/s）
- await：若持续 > 20ms（SSD 型云盘），说明请求在队列中等待过久，可能是队列打满或后端限速
- svctm 已废弃，不要参考；%util 接近 100% 不等于瓶颈——云盘是网络设备，%util 无物理意义
检查 Linux 层关键限制点
很多“慢”其实卡在系统配置，而非云盘后端：
- IO 调度器：云磁盘本质是远程块设备，应设为
none（AWS）、mq-deadline（阿里云推荐）或bfq（低延迟场景），避免 cfq 类调度器引入额外延迟 - 队列深度：
cat /sys/block/vda/device/queue_depth，默认常为 32；高并发场景建议调至 64~128（需确认云厂商支持） - 多路径与挂载选项 ：不用 multipath（云盘不适用），但挂载时加
noatime,nodiratime,barrier=0可减小元数据开销（仅限日志已落盘的场景）
定位真实瓶颈的三步法
别一上来就怀疑云厂商，先分层验证：
- 用
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --iodepth=64 --runtime=60 --time_based单独压测裸盘，看能否打满标称 IOPS - 在同样参数下测试文件系统层（如
fio --filename=/mnt/data/testfile），对比结果下降幅度：>15% 说明 FS 或挂载配置有问题 - 查
dmesg | grep -i "i/o"和cat /proc/diskstats，确认是否有 timeout、aborted、resets 等错误计数增长
