排查华为云 ECS 存储性能问题时，最常见的误区是只看容量：数据库数据量和日志保留空间看似充足，业务高峰仍可能出现 SQL 延迟、日志写入堆积或备份窗口超时，因为真正限制业务的可能是 IOPS、吞吐量、时延或 ECS 实例级存储 QoS。
本文给出一套可复现的诊断方法：先识别 I/O 模型，再从 CES 监控定位瓶颈，最后用安全的 fio 文件测试验证。重点是解释指标、复现方法和验证路径。
一、先分清三个指标
- IOPS：每秒完成多少次读写操作。MySQL、PostgreSQL、消息队列等大量 4KiB～16KiB 随机 I/O 的业务更敏感。
- 吞吐量：每秒传输多少数据。备份、恢复、日志归档、视频处理和大文件扫描更敏感。
- 时延：一次 I/O 从提交到完成需要多久。即使平均 IOPS 不高，较高的 P95/P99 时延也会拖慢接口响应。
同一块盘不能同时无限提高所有指标。4KiB 随机读更容易测出 IOPS，1MiB 顺序读写更容易测出吞吐量；测试块大小、队列深度和并发任务不同，结果也会明显不同。
二、不同盘型指标如何影响诊断
根据华为云云硬盘类型及性能介绍，通用型 SSD V2（GPSSD2）支持分别配置容量、IOPS 和吞吐量；极速型 SSD V2（ESSD2）的性能上限不同。诊断时不要仅凭盘型名称下结论，应把监控值、实例限制和测试结果放在一起分析。
常见于通用型 SSD V2 的负载特征
- Web 应用、企业系统和中小型数据库，负载有波峰但不是持续极限；
- 容量增长和性能增长不同步，希望分别调整；
- 已有监控数据，能给 IOPS、吞吐量设置合理余量；
- 希望先按业务需求配置，再根据上线数据变更性能。
华为云文档列出了通用型 SSD V2 的基准指标、可配置范围和约束公式；这些参数可能随产品更新变化，应以通用型 SSD V2 说明为准。诊断时更重要的是使用接近真实业务的块大小、读写比例和并发度验证，而不是机械套用单个标称值。
需要重点检查高性能盘上限的场景
- 高并发数据库、低时延缓存持久化或密集事务负载；
- 单盘确实需要超过通用型 SSD V2 的性能上限；
- 业务已经通过监控和压测证明瓶颈在存储，而不是 CPU、内存、锁等待或 SQL；
- ECS 规格能够承接测试所需的 IOPS 与吞吐量。
不要因为盘型名称直接判断故障原因。若业务只有低并发顺序写，瓶颈可能在吞吐量；若 ECS 实例级存储 QoS 更低，云硬盘也可能跑不到标称上限。
三、先从监控反推需求
排障前至少收集一个完整业务周期，优先观察高峰期而不是全天平均值。华为云 CES 的云硬盘监控指标包括读写带宽、读写 IOPS、平均队列长度、读写使用率和读写耗时，可用于判断瓶颈类型。
建议记录：
- 读 IOPS 与写 IOPS 的 P95、峰值；
- 读带宽与写带宽的 P95、峰值；
- 读写平均耗时是否在业务高峰同步上升；
- 队列长度是否持续堆积；
- 数据增长速度、快照与备份窗口；
- ECS 上所有云硬盘的 IOPS/吞吐量总和。
可以把"近期高峰值 × 业务增长系数 × 安全余量"作为初始测试目标，但余量不是固定百分比。流量稳定的内部系统可采用较小余量；周期性活动、批处理或突发写入明显的业务应覆盖峰值场景，并在变更后重新验证。
四、别漏掉 ECS 实例级存储 QoS
云硬盘上限不是最终上限。华为云文档明确说明：当同一 ECS 挂载的云硬盘性能总和超过实例规格的存储 I/O 能力时，最终性能受实例级存储 QoS 限制，多块盘之间还会争抢实例额度。
按下面顺序核对：
- 在 ECS 规格说明中找到实例存储 IOPS 与存储带宽上限；
- 汇总系统盘和所有数据盘的目标 IOPS、吞吐量；
- 确认总需求没有超过实例上限；
- 若超过，判断瓶颈来自实例上限、数据库集中部署还是多盘并发竞争；
- 调整测试条件后重新验证，确认变化是否符合预期。
这一步能避免"盘已经升配，但 fio 和数据库延迟几乎没变化"的无效投入。
五、在 Linux 上安全做 fio 验证
不要把裸盘写压测命令直接指向已有文件系统的设备。 华为云测试云硬盘性能特别提醒，裸盘 fio 可能破坏文件系统。生产环境应优先使用新建的测试盘；确需在文件系统上验证时，只操作专用测试文件，并提前备份、控制测试窗口和 I/O 压力。
先确认设备、挂载点和 4KiB 对齐；将示例中的 /dev/vdb 替换为实际测试盘设备名：
bash
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
findmnt -no SOURCE,TARGET,FSTYPE /mnt/evs-test
sudo fdisk -l /dev/vdb | sed -n '1,20p'以下假设一块新测试盘已经按官方流程初始化并挂载到 /mnt/evs-test。不要只在系统盘上新建同名目录，否则测到的是系统盘。安装工具后再次确认挂载点：
bash
# Ubuntu / Debian
sudo apt-get update && sudo apt-get install -y fio sysstat
# Rocky Linux / AlmaLinux
sudo dnf install -y fio sysstat
findmnt /mnt/evs-test || { echo "测试盘未挂载，停止压测"; exit 1; }以下命令只写入指定测试文件，不要把 --filename 改成业务盘设备名。先准备 10GiB 测试文件：
bash
sudo fio --name=prepare \
--filename=/mnt/evs-test/fiotest.dat \
--size=10G --rw=write --bs=1M \
--direct=1 --ioengine=libaio --iodepth=32 \
--group_reporting测试 4KiB 随机读，观察 IOPS 和时延：
bash
sudo fio --name=rand-read-4k \
--filename=/mnt/evs-test/fiotest.dat \
--size=10G --rw=randread --bs=4k \
--direct=1 --ioengine=libaio --iodepth=32 \
--runtime=120 --time_based --group_reporting测试 1MiB 顺序读，观察吞吐量：
bash
sudo fio --name=seq-read-1m \
--filename=/mnt/evs-test/fiotest.dat \
--size=10G --rw=read --bs=1M \
--direct=1 --ioengine=libaio --iodepth=32 \
--runtime=120 --time_based --group_reporting另开终端观察队列、利用率和等待时间：
bash
iostat -dx 1 120测试结束并确认文件路径后再删除测试文件：
bash
sudo rm -f /mnt/evs-test/fiotest.dat
六、怎么看测试结果
- 4KiB 随机读 IOPS 较低，同时 await 和队列持续升高：可能是云硬盘性能不足，也要核对 ECS QoS、测试并发和应用自身限制。
- 1MiB 顺序读很快，数据库仍慢：大块吞吐量不代表小块随机 I/O 能力，应回到 4KiB/8KiB 模型和 SQL 延迟。
- 多块盘单独测试正常，一起测试封顶：优先检查 ECS 实例级存储带宽或 IOPS 上限。
- fio 达标，接口仍慢：检查 CPU、内存换页、数据库锁、连接池、网络和应用代码，不要继续盲目升盘。
- 短时结果很高，持续压测回落：延长测试时间，并查看突发能力、缓存与稳定阶段数据。
压测值不能单独代表业务健康度。应把 fio、CES 和业务指标放在一起：磁盘达到预期只是必要条件，接口 P95/P99、数据库事务延迟、备份完成时间和错误率才是验证标准。
七、常见误区
- 只按容量买盘：空间够用不代表 IOPS、吞吐量和时延够用。
- 把 IOPS 和吞吐量混为一谈：随机小块与顺序大块是两类负载。
- 忽略 ECS QoS：多盘性能总和超过实例能力后，只调整单盘参数未必有效。
- 在业务裸盘上跑写压测：可能直接破坏文件系统和数据。
- 用一条 fio 命令代表所有业务：块大小、读写比例、队列深度必须接近真实负载。
- 只看平均值：容量规划应关注高峰、P95/P99 和增长趋势。
- 不做变更后复核：升配完成不等于瓶颈消失，应重新检查 CES 和应用指标。
八、形成可复现的诊断结论
完成监控分析与 fio 测试后，应记录测试时间、盘型、容量、IOPS、吞吐量、ECS 规格、队列深度、块大小、读写比例以及业务高峰指标。只有参数和环境完整，后续复测结果才具有可比性。
完整的闭环是：先量化业务高峰，再确认 ECS 与 EVS 的限制关系，然后用隔离测试盘验证，最后回到真实监控复核。 若调整后 CES 指标改善而业务延迟没有变化，应继续检查 SQL、锁等待、CPU、内存、网络和应用代码，避免把所有慢请求都归因于云硬盘。