You are on page 1of 10

云硬盘测试

我们通过两方面来提高云硬盘的性能的:
降低延迟(使用 SSD,使用万兆网络,优化代码,减少瓶颈)
提高并行度(数据分片,同时使用整个集群的所有 SSD)
在 Linux 下测试云硬盘
在 Linux 下,你可以使用 FIO 来测试
操作系统:Ubuntu 14.04
CPU: 2
Memory: 2GB
云硬盘大小: 1TB(SLA: 6000 IOPS, 170MB/s 吞吐率 )
安装 fio:
#sudo apt-get install fio
再次介绍一下 FIO 的测试参数:
ioengine: 负载引擎,我们一般使用 libaio,发起异步 IO 请求。
bs: IO 大小
direct: 直写,绕过操作系统 Cache。因为我们测试的是硬盘,而不是操作系统的 Cache,所
以设置为 1。
rw: 读写模式,有顺序写 write、顺序读 read、随机写 randwrite、随机读 randread 等。
size: 寻址空间,IO 会落在 [0, size)这个区间的硬盘空间上。这是一个可以影响 IOPS 的参数。
一般设置为硬盘的大小。
filename: 测试对象
iodepth: 队列深度,只有使用 libaio 时才有意义。这是一个可以影响 IOPS 的参数。
runtime: 测试时长
4K 随机写测试
我们首先进行 4K 随机写测试,测试参数和测试结果如下所示:
#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=100G -filename=/dev/vdb
-name="EBS 4KB randwrite test" -iodepth=32 -runtime=60
蓝色方框表示 IOPS 是 5900,在正常的误差范围内。绿色方框表示 IO 请求的平均响应时间
为 5.42ms, ***方框表示 95%的 IO 请求的响应时间是小于等于 6.24 ms 的。
4K 随机读测试
我们再来进行 4K 随机读测试,测试参数和测试结果如下所示:
#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randread -size=100G -filename=/dev/vdb
-name="EBS 4KB randread test" -iodepth=8 -runtime=60
512KB 顺序写测试
最后我们来测试 512KB 顺序写,看看云硬盘的最大 MBPS(吞吐率)是多少,测试参数和测
试结果如下所示:
#fio -ioengine=libaio -bs=512k -direct=1 -thread -rw=write -size=100G -filename=/dev/vdb
-name="EBS 512KB seqwrite test" -iodepth=64 -runtime=60
蓝色方框表示 MBPS 为 174226KB/s,约为 170MB/s。
使用 dd 测试吞吐率
其实使用 dd 命令也可以测试出 170MB/s 的吞吐率,不过需要设置一下内核参数,详细介绍
在 128MB/s VS 170MB/s 章节中。
在 Windows 下测试云硬盘
在 Windows 下,我们一般使用 IOMeter 测试磁盘的性能,IOMeter 不仅功能强大,而且很
专业,是测试磁盘性能的首选工具。
IOMeter 是图形化界面(浓浓的 MFC 框架的味道),非常方便操作,下面我将使用 IOMeter
测试我们 UOS 上 1TB 的云硬盘。
操作系统:Window Server 2012 R2 64
CPU: 4
Memory: 8GB
云硬盘大小: 1TB
当你把云硬盘挂载到 Windows 主机之后,你还需要在 windows 操作系统里面设置硬盘为联
机状态。
4K 随机写测试
打 开 IOMeter( 你 需 要 先 下 载 ) , 你 会 看 到 IOMeter 的 主 界 面 。 在 右 边 , 你 回 发 现 4 个
worker(数量和 CPU 个数相同),因为我们现在只需要 1 个 worker,所以你需要把其他 3 个
worker 移除掉。
现在让我们来测试硬盘的 4K 随机写,我们选择好硬盘(Red Hat VirtIO 0001),设置寻址空
间 (Maximum Disk Size) 为 50GB( 每 个 硬 盘 扇 区 大 小 是 512B , 所 以 一 共 是
50*1024*1024*1024/512 = 104857600),设置队列深度(Outstanding I/Os)为 64。

然后在测试集中选择”4KiB ALIGNED; 0% Read; 100% random(4KB 对齐,100%随机写操


作)” 测试
然后设置测试时间,我们设置测试时长为 60 秒,测试之前的预热时间为 10 秒(IOMeter 会
发起负载,但是不统计这段时间的结果)。

在最后测试之前,你可以设置查看实时结果,设置实时结果的更新频率是 5 秒钟。最后点击
绿色旗子开始测试。
在测试过程中,我们可以看到实时的测试结果,当前的 IOPS 是 6042,平均 IO 请求响应时
间是 10.56ms,这个测试还需要跑 38 秒,这个测试轮回只有这个测试。

我们可以看到 IOMeter 自动化程度很高,极大解放测试人员的劳动力,而且可以导出 CSV


格式的测试结果。
顺序读写测试
我们再按照上面的步骤,进行了顺序读/写测试。下面是测试结果:
IO 大小 读写模式 队列深度 MBPS
顺序写吞吐测试 512KB 顺序写 64 164.07 MB/s

顺序读吞吐测试 256KB 顺序读 64 179.32 MB/s

云硬盘的响应时间
当前云硬盘写操作的主要延迟是
网络传输
多副本,写三份(数据强一致性)
三份数据都落盘(数据持久化)之后,才返回
IO 处理逻辑
我们当前主要是优化 IO 处理逻辑,并没有去优化 2 和 3,这是因为我们是把用户数据的安
全性放在第一位。
128MB/s VS 170MB/s
回到最开始的问题 “为什么使用 dd 命令测试云硬盘只有 128MB/s”, 这是因为目前云硬盘
在处理超大 IO 请求时的延迟比 SSD 高(我们会不断进行优化),现在我们有两种方法来获得
更高的 MBPS:
设置 max_sectors_kb 为 256 (系统默认为 512),降低延迟
使用 fio 来测试,加大队列深度
通过设置 max_sectors_kb 这个参数,使用 dd 也可以测出 170MB/s 的吞吐量
root@ustack:~# cat /sys/block/vdb/queue/max_sectors_kb
512
root@ustack:~# echo "256" > /sys/block/vdb/queue/max_sectors_kb
root@ustack:~#
root@ustack:~# dd if=/dev/zero of=/dev/vdb bs=32M count=40 oflag=direct
40+0 records in
40+0 records out
1342177280 bytes (1.3 GB) copied, 7.51685 s, 179 MB/s
root@ustack:~#
同时查看 IO 请求的延迟:
root@ustack:~# iostat -x vdb 5 100
...
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vdb 0.00 0.00 0.00 688.00 0.00 176128.00 512.00 54.59 93.47 0.00 93.47 1.40 96.56
下面是使用 fio 工具的测试结果,也可以得到 170MB/s 的吞吐率。
不可测试的指标
IOPS 和 MBPS 是用户可以使用工具测试的指标,云硬盘还有一些用户不可测量的指标
数据一致性
数据持久性
数据可用性
这些指标我们只能通过根据系统架构和约束条件计算得到,然后转告给用户。这些指标衡
量着公有云厂商的良心,有机会会专门进行介绍。

总结
上面介绍了一下测试工具和一些观点,希望对你有所帮助。
测试需要定性和定量
了解存储模型可以帮助你更好的进行测试
增加队列深度可以有效测试出 IOPS 和 MBPS 的峰值