Google Cloud的云硬盘在官方文档里都会标注一个理论IOPS上限，但实际业务中真正能跑到多少，取决于磁盘类型、实例vCPU数量、队列深度、数据块大小等一系列因素。很多用户在迁移业务到GCP之后发现数据库性能不如预期，第一反应是怀疑网络，其实问题往往出在存储子系统上。本文将使用业界标准的fio工具，在Google Compute Engine的不同磁盘配置上完整测试4K随机读写IOPS，并逐项分析影响性能的关键因素。
测试环境与fio安装配置
本次测试选用的是Compute Engine的n2-standard-8实例，配备8个vCPU和32GB内存，这个规格足以让磁盘性能不受CPU瓶颈的限制。测试磁盘选择了三种类型：pd-balanced、pd-ssd以及新一代的hyperdisk-balanced，容量统一为500GB，挂载在独立设备上，避免系统盘的干扰。
fio在Debian和Ubuntu上可以直接通过apt-get install fio安装，CentOS用户使用yum install fio即可。安装完成后先确认版本，建议使用4.x以上的版本，因为新版本对io_uring引擎的支持更完善，测试结果更贴近真实内核IO路径：
fio --version # 输出类似 fio-3.28 即可 # 确认磁盘设备名 lsblk # 假设测试盘为 /dev/sdb，挂载到 /mnt/testdisk # 格式化并挂载（测试盘数据会清空，注意备份） mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/testdisk
需要特别说明的是，GCP的持久化磁盘是网络存储，官方明确建议在正式基准测试之前先做预热（ preconditioning），写入足够的数据让磁盘进入稳定状态，否则首次写入的测试结果可能虚高或偏低，不具备参考价值。预热可以在实例内部用dd或者fio本身完成：
# 用fio写入整个磁盘做预热，bs=1M顺序写
fio --name=precondition --filename=/dev/sdb \
--rw=write --bs=1M --iodepth=64 --direct=1 \
--ioengine=libaio --runtime=1800 --time_based4K随机读写的fio测试命令详解
预热完成后，就可以开始正式测试。4K随机读的标准测试命令如下，其中几个关键参数必须理解：--direct=1表示绕过操作系统页缓存直接读写磁盘，这是获得真实磁盘性能的前提；--iodepth控制并发IO请求数，直接决定了能否打满磁盘的IOPS上限；--runtime配合--time_based保证测试持续固定时间而不是写完固定数据量就结束。
# 4K随机读测试
fio --name=randread --filename=/mnt/testdisk/fiotest \
--rw=randread --bs=4k --iodepth=32 --direct=1 \
--ioengine=libaio --runtime=300 --time_based \
--group_reporting --numjobs=4 \
--output=randread.txt
# 4K随机写测试
fio --name=randwrite --filename=/mnt/testdisk/fiotest \
--rw=randwrite --bs=4k --iodepth=32 --direct=1 \
--ioengine=libaio --runtime=300 --time_based \
--group_reporting --numjobs=4 \
--output=randwrite.txt--numjobs=4表示启动4个并行线程，这在GCP上很关键。因为持久化磁盘的IOPS配额是按磁盘计算的，单个线程受限于队列深度，多线程才能充分压榨性能。测试结束后fio会输出详细报告，重点关注read部分或write部分的iops和lat字段，前者是每秒IO次数，后者是延迟分布，两者需要结合看，单纯追求高IOPS而忽略延迟没有意义。
实测结果与性能分析
在n2-standard-8实例上，500GB的三种磁盘实测数据大致如下：pd-balanced的4K随机读约在15000 IOPS左右，随机写在9000 IOPS上下；pd-ssd读取能稳定到官方标称的15000 IOPS，写入接近；hyperdisk-balanced在配置为20000 IOPS时基本可以跑满配额，且延迟表现明显更平稳，p99延迟控制在2毫秒以内。
队列深度对结果的影响非常显著。将--iodepth从1逐步调整到64，IOPS呈明显上升趋势，iodepth=1时三种磁盘都只能跑到2000 IOPS左右，延迟约0.4毫秒；当iodepth提升到32之后基本进入平台期。这说明GCP持久化磁盘对并发IO的容忍度较高，业务侧如果使用异步IO框架，务必配置足够的并发连接数，否则磁盘配额再高也用不满。
另一个容易被忽视的因素是实例的vCPU数量。GCP规定每GB持久化磁盘的性能与实例vCPU数挂钩，vCPU越少的实例，即使挂载了高配磁盘，实际能达到的IOPS也会被限流。测试中如果在n2-standard-2上重复同样的测试，IOPS会下降到原来的三分之一左右。因此在评估性能预算时，磁盘配额和实例规格必须一起考虑，不能只看磁盘标称值。
此外还有几个测试细节值得注意：每次测试前执行echo 3 > /proc/sys/vm/drop_caches清理缓存（虽然direct模式下影响不大，但多一层保险）；同一种配置至少跑三遍取平均值；测试文件大小建议设置为磁盘容量的两倍以上以覆盖足够的数据空间；报告中的stdev（标准差）如果异常大，说明磁盘性能不稳定，需要检查是否与其他业务共用了带宽配额。
如何根据测试结果做优化选型
从测试结论看，不同的业务场景应该选择不同的磁盘组合。OLTP数据库这类以4K随机读写为主的负载，hyperdisk-balanced是性价比最优的选择，它支持自定义IOPS和吞吐量配置，可以精确匹配业务需求，避免为用不到的配额付费。如果预算有限且读写比例均衡，pd-balanced足够应付中等规模的数据库。pd-ssd则更适合读多写少、对延迟敏感的场景。
如果实测IOPS距离配额还有明显差距，可以从三个方向排查：第一，确认内核IO调度器是否为none或mq-deadline，在GCP官方镜像中通常已默认配置；第二，检查应用程序是否使用了同步IO，必要时改造为libaio或io_uring异步引擎；第三，确认磁盘是否跨多个实例共享使用，共享会分摊配额。通过fio的定期回归测试，还可以监控磁盘性能是否随时间劣化，为容量规划提供数据支撑。
总的来说，fio是一款轻量但功能完备的存储测试工具，配合合理的参数设计，可以准确还原Google Cloud磁盘的真实4K随机读写能力。建议在业务上线前都执行一轮完整基准测试，把理论规格转化为实测数据，这样才能做出靠谱的架构决策。
Google CloudfioIOPS修改时间：2026-09-01 09:46:34