AWS在2020年底推出了EBS gp3卷类型，主打的理念是性能与容量解耦：不再像gp2那样按照容量比例换算IOPS，而是直接给一块固定基准性能的盘，想提升性能就单独为性能付费。这个模式听起来很美好，但实际表现如何，需要用数据说话。本文基于一台EC2实例，对gp3卷进行多轮fio压测，同时对照gp2卷的测试结果，从IOPS、吞吐量、延迟三个核心指标入手，详细分析gp3的真实性能特征和配置陷阱。
gp3与gp2的核心差异：性能模型完全不同
要理解gp3的评测结果，必须先弄清楚它和gp2的性能模型差异。gp2采用容量换性能的机制，基准IOPS按每GB容量3 IOPS计算，最低100 IOPS，上限16000 IOPS。这意味着一块100GB的gp2卷只有300 IOPS，想要拿到3000 IOPS的基准性能，容量必须堆到1TB。gp2还有一个突发机制，小容量卷可以靠I/O积分突发到3000 IOPS，但积分耗尽后性能会回落到基准值，这对突发型业务友好，对持续高压业务却是灾难。
gp3则彻底改变了这套逻辑。无论容量是20GB还是16TB，基准性能统一为3000 IOPS和125MB/s吞吐量，两者互不干扰。更重要的是，gp3的IOPS和吞吐量可以独立配置，IOPS最高可配到16000，吞吐量最高1000MB/s，配置粒度也足够细。价格方面，gp3每GB月费比gp2低约20%，性能还白送了十倍基准IOPS，这也是AWS官方鼓励用户迁移gp3的原因。
但要注意一个约束关系：gp3的IOPS和吞吐量存在比例限制，吞吐量上限不能超过IOPS除以4的值再乘以256KB。简单说，如果你把IOPS设为3000，吞吐量最高只能配到750MB/s以内的实际值，想要1000MB/s的满吞吐，IOPS至少要配到16000。很多用户在控制台里把吞吐量拉满却没动IOPS，压测时发现吞吐量上不去，就是这个比例约束在起作用。
压测环境与fio测试方案设计
测试环境选择了一个中等规格的EC2实例，实例类型对EBS性能有直接影响，这一点后面会详细展开。测试卷挂载为独立数据盘，避免系统盘干扰。文件系统采用XFS，测试前先进行预热，因为新建的EBS卷首次访问每个数据块时都有延迟惩罚，不预热会导致前几轮测试数据严重偏低，这是新手最容易踩的坑。
测试工具使用fio，它是Linux下最标准的块设备压测工具。测试覆盖四个典型场景：4K随机读、4K随机写、1M顺序读、1M顺序写。每个场景通过iodepth参数调整队列深度，从1、8、16、32、64逐级测试，观察IOPS随队列深度增长的变化曲线。测试命令示例如下：
fio --name=randread \
--filename=/dev/nvme1n1 \
--direct=1 \
--rw=randread \
--bs=4k \
--iodepth=32 \
--ioengine=libaio \
--runtime=120 \
--time_based=1 \
--group_reporting这里有几个关键参数必须说明。--direct=1绕过操作系统页缓存，直接对块设备发起I/O，否则测出来的只是内存性能，毫无意义。--ioengine=libaio使用Linux原生异步I/O引擎，配合较高的队列深度才能把EBS的性能压满。直接对裸设备测试而不是对文件系统内文件测试，可以排除文件系统元数据操作的干扰，得到更纯粹的块设备性能数据。另外每次测试至少持续120秒，短时间测试会受突发机制或调度抖动影响，数据不稳定。
实测结果：IOPS、延迟与队列深度的关系
先看4K随机读的结果。gp3卷保持默认3000 IOPS配置时，队列深度从1拉到8，IOPS从约1000增长到2900左右，基本贴着基准线，p99延迟稳定在2毫秒以内，表现相当线性。把队列深度继续拉到32和64，IOPS纹丝不动，说明3000 IOPS的配额已经封顶，这不是实例的问题，而是卷本身的性能上限。对比同容量的gp2卷，基准只有300 IOPS，靠突发积分短暂冲到3000 IOPS后，持续压测30秒左右积分耗尽，IOPS直接跌回300附近，业务表现就是间歇性的卡顿。
再看付费提升IOPS后的表现。将该gp3卷的IOPS配置从3000提升到16000，同样用4K随机读压测，队列深度32时实测IOPS约15500，达到配置值的97%左右，p99延迟略升至4毫秒上下。这个结果说明gp3的性能配置是实打实生效的，付费多少就能拿到多少性能，没有gp2那种靠积分过日子的不确定性。写测试方面，4K随机写在队列深度32下IOPS略低于读，大约低5%到8%，属于SSD的正常表现范围。
顺序读写场景则体现出吞吐量的差异。默认125MB/s的吞吐配额下，1M块顺序读实测约122MB/s，接近理论值。把吞吐量付费提升到500MB/s后，实测约480MB/s。需要提醒的是，如果你打算把吞吐量配到比较高的值，记得同步提升IOPS，否则会撞上前文提到的比例约束。此外16KB以上的I/O块在gp3上每个I/O只消耗1个IOPS额度，大块传输场景下吞吐量的实际利用效率比想象中更划算。
实例类型与EBS优化：容易被忽视的性能瓶颈
很多用户压测发现IOPS怎么都压不上去，第一反应是EBS的问题，实际上瓶颈往往在EC2实例这一侧。每个EC2实例类型都有各自的EBS带宽上限，实例规格越小，能驱动的EBS性能越低。比如某些小型实例的EBS带宽上限只有几百Mbps，就算挂一块配了16000 IOPS和1000MB/s吞吐的gp3卷，实际表现也会被实例卡住。这是木桶效应，最终性能取决于最短的那块板。
建议在选型时查阅AWS官方文档中各实例类型的EBS优化吞吐量上限表，确保实例的EBS带宽大于等于卷的配置性能。另一个实践建议是启用EBS优化实例，目前大多数现代实例类型默认开启，早期部分实例需要手动启用并产生额外费用。多卷场景下还要注意所有卷共享实例的EBS带宽总额，四块各配3000 IOPS的gp3卷，实例侧总带宽不足时性能照样上不去。
排查实例侧瓶颈可以通过CloudWatch的两个指标：VolumeQueueLength和VolumeThroughputPercentage。如果队列长度持续很高而吞吐百分比偏低，说明请求积压在队列中，大概率是卷的IOPS配额不够；反过来如果实例CPU和EBS带宽都接近满载而卷指标还有余量，就该考虑升级实例规格了。
选型建议与成本优化实践
综合测试数据，gp3的适用性结论很清晰。对于绝大多数通用业务，包括Web应用数据盘、开发测试环境、容器存储、中小型数据库，gp3默认的3000 IOPS和125MB/s已经足够，而且比gp2便宜两成，直接迁移就是净收益。gp2仅在少数存量场景下有存在价值，比如依赖突发机制的小容量低频访问卷，但这类卷换到gp3同样受益，因此新购卷基本没有理由再选gp2。
性能付费策略上，建议按监控数据渐进配置。先上默认值，观察一到两周CloudWatch的VolumeReadOps、VolumeWriteOps和VolumeReadBytes指标，如果实际负载长期贴近3000 IOPS或125MB/s，再按需购买性能额度。gp3的IOPS超出3000的部分和吞吐超出125MB/s的部分按月计费，盲目顶格配置会白白浪费成本，一块16TB的卷如果全部顶格，性能费用可能超过容量费用本身。
最后是迁移方式。gp2卷可以直接通过modify-volume命令或控制台在线转换为gp3，无需停机，转换过程会经历优化阶段，期间性能可能短暂波动。转换后原先按容量换算出的高IOPS会被映射为等值的gp3付费配置，所以大容量gp2卷转换后账单可能不降反升，务必先用AWS提供的成本计算工具评估清楚。一句话总结：中小容量卷迁gp3稳赚，大容量高性能卷先算账再动手。