← 返回首页

雨云的高效云盘怎么样

阅读约 4 分钟#服务器 #储存
目录

在雨云购买服务器时,发现部分地区的服务器有高效云盘的配置,且描述为“性价比高,容量大,适合小型低负载通用场景”,网上很少相关测评,于是我购买了一个搭配高效云盘的服务器部署我的博客,顺手测试了下这个高效云盘的性能。

WARNING
这个测试是在非常不严谨的条件与环境下进行测试的,仅供参考,本人也不会评价这个云盘(但是交给AI评价)

测试内容 #

WARNING
测试指令由AI生成
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(应用无响应)弹窗。

评论