云服务器的存储性能不能只看顺序读写速度。4K随机读写代表着小块数据分散访问的能力，直接决定数据库查询、消息队列持久化和虚拟内存交换的响应时间。在Vultr的套餐体系中，NVMe本地盘、普通SSD和Block Storage网络盘三种存储类型在4K随机IOPS上差距很大。本文用fio模拟真实工作负载，测试不同队列深度下的结果，并分析这些数字对实际业务意味着什么。
为什么4K随机读写IOPS是关键指标
IOPS即每秒输入输出操作次数，用来衡量存储设备处理大量小块请求的能力。4K块大小之所以重要，是因为操作系统、数据库页和文件系统元数据普遍使用4K或接近4K的分配单位。顺序读写测试通常使用1MB大块，能够掩盖存储介质在寻址和调度上的短板，而4K随机读写则是让数据分散在整块盘上，强制存储系统暴露真实的请求处理能力。
数据库的B+树索引节点通常以16K或4K为单位进行读取，查询操作很少是顺序连续的。一次索引查找可能触发多次随机读，如果4K随机读IOPS不足，即使CPU核心空闲，查询延迟也会被磁盘等待拉高。高并发Web应用在读取大量小图片、静态文件或会话数据时，同样容易遇到类似瓶颈。因此，4K随机读写IOPS比顺序带宽更能反映Vultr云服务器在高负载场景下的实际表现。
Vultr提供的存储类型包括本地NVMe、普通SSD和网络型Block Storage。本地NVMe通过PCIe通道直连CPU，具有最低的软件栈开销和最高的队列并行能力；普通SSD虽然也是本地盘，但受限于SATA或较老的NVMe控制器，性能会明显下降；Block Storage则是通过内部网络挂载的远端存储，多了一层网络协议栈，IOPS天然不占优势。这些差异在fio的4K随机测试中会被进一步放大。
fio测试环境与参数说明
本次测试在Ubuntu系统上进行，安装fio只需要执行sudo apt update && sudo apt install fio -y。测试前需要确认目标分区或磁盘有足够剩余空间，避免测试文件写满影响结果。对于本地NVMe，可以直接使用--filename=/dev/nvme0n1p1，如果担心破坏系统，也可以在挂载目录下创建测试文件，但文件系统层会略微增加开销。
fio参数中，--bs=4k指定块大小为4K，--rw=randread表示纯随机读，--rw=randwrite表示纯随机写，--rw=randrw配合--rwmixread=70可以模拟70%读30%写的混合负载。--iodepth代表每个任务的异步队列深度，--numjobs是并发任务数，两者相乘才是总队列深度。--ioengine=libaio启用Linux异步IO，--direct=1绕过页缓存，确保测试数据来自真实磁盘而不是内存。
下面给出三组典型测试命令，分别对应4K随机读、随机写和混合读写。运行时间建议设置为60秒，避免短时间测试被缓存或主控突发性能干扰。
# 4K随机读测试 fio --name=randread --filename=/dev/nvme0n1p1 --size=10G --rw=randread --bs=4k --iodepth=32 --numjobs=4 --ioengine=libaio --direct=1 --time_based --runtime=60 --group_reporting # 4K随机写测试 fio --name=randwrite --filename=/dev/nvme0n1p1 --size=10G --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 --ioengine=libaio --direct=1 --time_based --runtime=60 --group_reporting # 70%读30%写混合测试 fio --name=randrw --filename=/dev/nvme0n1p1 --size=10G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --ioengine=libaio --direct=1 --time_based --runtime=60 --group_reporting
Vultr三种存储的4K随机IOPS实测结果
本次对比以Vultr High Frequency套餐的128GB本地NVMe、Regular Cloud Compute套餐的80GB普通SSD以及附加的100GB Block Storage为例。每轮测试使用10GB测试文件，队列深度从1逐步增加到32，记录稳定后的平均IOPS和P99延迟。结果如下表所示。
| 存储类型 | 4K随机读IOPS | 4K随机写IOPS | P99读延迟 | P99写延迟 |
|---|---|---|---|---|
| 本地NVMe | 85000 | 42000 | 0.6ms | 1.2ms |
| 普通SSD | 32000 | 12500 | 1.5ms | 3.8ms |
| Block Storage | 5800 | 2100 | 5.2ms | 9.6ms |
从数据可以看出，本地NVMe在4K随机读上几乎是普通SSD的2.6倍，随机写差距超过3倍。普通SSD在队列深度达到16以后提升幅度明显变小，说明其主控调度能力或NAND通道数量已经成为瓶颈。Block Storage由于经过内部网络往返，IOPS不到本地NVMe的七分之一，P99延迟也达到了5毫秒以上，不适合对延迟敏感的业务。
写IOPS普遍低于读IOPS，这是NAND闪存的工作特性决定的。写入时需要先擦除块，同时主控还要执行垃圾回收和磨损均衡，这会产生写放大。云平台也可能对持续高写入进行限速。测试中还观察到本地NVMe在随机写达到峰值后会出现周期性波动，这通常是主控后台GC任务短暂占用资源所致，属于正常现象。
如何根据IOPS选择Vultr套餐与优化建议
如果运行MySQL或PostgreSQL这类关系型数据库，4K随机读是主要压力来源。本地NVMe机型配合足够大的innodb_buffer_pool_size能够显著降低磁盘读次数，当数据量超过内存时，高随机读IOPS可以保证索引查找保持在较低延迟。对于Redis持久化场景，混合读写性能更重要，70/30混合负载下本地NVMe通常仍能保持接近6万IOPS，而普通SSD可能会下降到两万左右。
如果是静态文件服务、备份或归档类应用，Block Storage容量大、成本低，虽然4K随机IOPS不高，但顺序带宽尚可，适合作为附加存储使用。不过日志收集、消息队列等高写入频率的工作负载不建议使用Block Storage，因为随机写IOPS不足会直接拖垮消费速度。将数据库日志文件与数据文件分离到不同的存储类型上，也能减少争抢。
优化层面，首先要根据实际应用的并发程度调整队列深度和任务数，队列深度不是越高越好，过高会引入额外的排队延迟。文件系统建议选择ext4并开启noatime挂载选项，减少元数据写入。数据库层面尽量合并小事务，避免频繁刷盘。最后，不要在测试或生产环境中只关注平均延迟，P99和P99.9延迟更能反映用户体验，选择存储时应综合参考IOPS和尾部延迟。
针对需要限制目标IOPS的场景，可以使用--rate_iops参数模拟应用的真实压力，例如--rate_iops=30000可以测试存储在该负载下的延迟表现。这样比单纯跑满盘更能判断未来业务增长时的余量。
Vultrfio4K随机读写IOPS修改时间：2026-08-27 23:05:51