雨云的高效云盘怎么样
目录
在雨云购买服务器时,发现部分地区的服务器有高效云盘的配置,且描述为“性价比高,容量大,适合小型低负载通用场景”,网上很少相关测评,于是我购买了一个搭配高效云盘的服务器部署我的博客,顺手测试了下这个高效云盘的性能。
测试内容 #
fio --name=realsqlite --direct=1 --fsync=1 --rw=randwrite --bs=4k --size=1G --numjobs=1 --runtime=60 --group_reporting
- 内容:模拟sqlite随机读写性能。
--bs=4k:数据块大小固定为 4KB。--rw=randwrite:执行随机写入。--direct=1:使用 O_DIRECT(直接 I/O),绕过操作系统的页缓存(Page Cache)。数据不经过内存缓冲,直接下发到存储设备。--fsync=1:每次写入完成后强制调用fsync(),要求设备将数据真正落盘(写入闪存颗粒)后才返回成功。--size=1G:测试文件大小 1GB,确保足够覆盖设备缓存区域。--runtime=60:运行 60 秒,统计平均表现。--numjobs=1:单线程,模拟单任务应用的数据库写入压力。
测试结果 #
fio --name=realsqlite --direct=1 --fsync=1 --rw=randwrite --bs=4k --size=1G --numjobs=1 --runtime=60 --group_reporting
realsqlite: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.39
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=336KiB/s][w=84 IOPS][eta 00m:00s]
realsqlite: (groupid=0, jobs=1): err= 0: pid=193329: Thu Aug 20 15:05:08 2026
write: IOPS=134, BW=536KiB/s (549kB/s)(31.4MiB/60005msec); 0 zone resets
clat (usec): min=995, max=352061, avg=3039.83, stdev=10184.75
lat (usec): min=996, max=352062, avg=3040.75, stdev=10184.76
clat percentiles (usec):
| 1.00th=[ 1254], 5.00th=[ 1336], 10.00th=[ 1401], 20.00th=[ 1467],
| 30.00th=[ 1549], 40.00th=[ 1614], 50.00th=[ 1713], 60.00th=[ 1876],
| 70.00th=[ 2180], 80.00th=[ 2966], 90.00th=[ 4146], 95.00th=[ 5866],
| 99.00th=[ 18744], 99.50th=[ 34341], 99.90th=[200279], 99.95th=[223347],
| 99.99th=[350225]
bw ( KiB/s): min= 16, max= 720, per=100.00%, avg=538.33, stdev=130.00, samples=119
iops : min= 4, max= 180, avg=134.57, stdev=32.50, samples=119
lat (usec) : 1000=0.01%
lat (msec) : 2=65.19%, 4=23.97%, 10=8.61%, 20=1.30%, 50=0.52%
lat (msec) : 100=0.19%, 250=0.17%, 500=0.02%
fsync/fdatasync/sync_file_range:
sync (usec): min=85, max=214894, avg=4401.51, stdev=5628.50
sync percentiles (msec):
| 1.00th=[ 3], 5.00th=[ 3], 10.00th=[ 3], 20.00th=[ 3],
| 30.00th=[ 4], 40.00th=[ 4], 50.00th=[ 4], 60.00th=[ 4],
| 70.00th=[ 5], 80.00th=[ 6], 90.00th=[ 7], 95.00th=[ 9],
| 99.00th=[ 16], 99.50th=[ 18], 99.90th=[ 41], 99.95th=[ 157],
| 99.99th=[ 215]
cpu : usr=0.59%, sys=1.47%, ctx=16315, majf=0, minf=11
IO depths : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,8047,0,8046 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=536KiB/s (549kB/s), 536KiB/s-536KiB/s (549kB/s-549kB/s), io=31.4MiB (33.0MB), run=60005-60005msec
Disk stats (read/write):
sda: ios=17/24414, sectors=792/278856, merge=0/10382, ticks=188/61403, in_queue=62578, util=95.63%
AI分析 #
一、测试的整体完成情况与平均吞吐表现
- 测试在 60 秒内实际只写入了 31.4 MiB 数据(远小于设定的 1GB 目标),这是因为存储设备处理速度跟不上,60 秒结束时只推进了这么多。
- 平均 IOPS 仅为 134,平均带宽只有 536 KiB/s(约 0.5 MB/s)。这个数值极其低下,甚至低于很多普通 U 盘的持续写入速度,说明该存储介质的物理写入能力存在严重瓶颈。
- 磁盘繁忙度(util)高达 95.63%,意味着存储设备几乎在整个 60 秒内都处于 100% 饱和状态,没有任何空闲时间来处理额外的 I/O 请求。
二、写入延迟(clat)的分布与极端波动情况
- 延迟的平均值约为 3.04 毫秒,看起来似乎尚可,但标准差高达 10184.75 微秒(约 10 毫秒),说明延迟波动极为剧烈,数据非常分散。
- 观察百分位数,能清晰看到“长尾延迟”极其恶劣:
- 50% 的操作(中位数)延迟为 1.7 毫秒,还算流畅。
- 90% 的操作延迟为 4.1 毫秒,依然在可接受范围内。
- 但到了 99% 时,延迟暴涨至 18.7 毫秒,开始出现轻微卡顿感。
- 99.9% 的延迟达到 200.3 毫秒,已经属于严重卡顿。
- 最极端的 99.99% 延迟高达 350.2 毫秒,这意味着在测试过程中,个别写入操作需要耗费三分之一秒才能完成。
- 延迟分布呈现明显的“两极分化”:约 65.19% 的操作在 2 毫秒内完成,但仍有约 0.19% 的操作延迟超过 100 毫秒,这种长尾现象是导致系统偶尔“无响应”或“掉帧”的直接原因。
三、强制落盘(fsync)操作的耗时分析
- 由于开启了
--fsync=1,每次写入后都要等待数据真正固化到物理介质。fsync的平均耗时为 4.4 毫秒。- 但从百分位看,其长尾同样严重:
- 50% 的 fsync 耗时 4 毫秒,表现正常。
- 90% 耗时 7 毫秒,尚可。
- 99% 耗时 16 毫秒,有明显延迟。
- 最极端的 99.99% 耗时达到了 215 毫秒。
- 这说明该设备在进行物理写入并确认落盘时,偶尔会遇到极大的内部阻力(可能是闪存垃圾回收 GC 或坏块重映射),导致写入确认被严重阻塞。
四、最终结论
- 性能评级:极差,完全无法胜任现代操作系统或数据库(尤其是 SQLite)的日常写入负载。
- 稳定性评级:极不稳定,尾部延迟过长,在真实应用场景中会频繁导致 App 卡死或 ANR(应用无响应)弹窗。

评论