[toc]
每个硬盘都有一个磁头(相当于银行的柜台),硬盘的工作方式是:
上图中蓝色方框里面的是测出的IOPS 230, 绿色方框里面是每个IO请求的平均响应时间,大约是4.3ms。黄色方框表示95%的IO请求的响应时间是小于等于 9.920 ms。橙色方框表示该硬盘的利用率已经达到了98.58%。 下面是 iodepth = 4 的测试:
我们发现这次测试的IOPS没有提高,反而IO平均响应时间变大了,是17ms。 为什么这里提高队列深度没有作用呢,原因当队列深度为1时,硬盘的利用率已经达到了98%,说明硬盘已经没有多少空闲时间可以压榨了。而且响应时间为 4ms。 对于SATA硬盘,当增加队列深度时,并不会增加IOPS,只会增加响应时间。这是因为硬盘只有一个磁头,并行度是1, 所以当IO请求队列变长时,每个IO请求的等待时间都会变长,导致响应时间也变长。 这是以前用IOMeter测试一块SATA硬盘的4K随机写性能,可以看到IOPS不会随着队列深度的增加而增加,反而是平均响应时间在倍增。
我们发现,当设置size=1GB时,IOPS会显著提高到568,IO平均响应时间会降到7ms(队列深度为4)。这是因为当寻址空间为1GB时,磁头需要移动的距离变小了,每次IO请求的服务时间就降低了,这就是空间局部性原理。假如我们测试的RAID卡或者是磁盘阵列(SAN),它们可能会用Cache把这1GB的数据全部缓存,极大降低了IO请求的服务时间(内存的写操作比硬盘的写操作快很1000倍)。所以设置寻址空间为1GB的意义不大,因为我们是要测试硬盘的全盘性能,而不是Cache的性能。
RAID卡厂商优化的方法也是降低服务时间:
磁盘阵列厂商通过以下手段降低服务时间:
推荐用IOMeter进行测试,使用大队列深度,并进行长时间测试,这样可以测试出SSD的真实性能。 下图是storagereview对一些SSD硬盘做的4KB随机写的长时间测试,可以看出有些SSD硬盘的最大响应时间很不稳定,会飙高到几百ms,这是不可接受的。
蓝色方框表示IOPS是5900,在正常的误差范围内。绿色方框表示IO请求的平均响应时间为5.42ms, 黄色方框表示95%的IO请求的响应时间是小于等于 6.24 ms的。
现在让我们来测试硬盘的4K随机写,我们选择好硬盘(Red Hat VirtIO 0001),设置寻址空间(Maximum Disk Size)为50GB(每个硬盘扇区大小是512B,所以一共是 50*1024*1024*1024/512 = 104857600),设置队列深度(Outstanding I/Os)为64。
问题
UOS公有云开放以来,一些用户反应用dd命令测试出来的1TB云硬盘的吞吐率(MBPS)只有128MB/s,而不是我们SLA保证的170MB /s ,这是为什么?下面我会简单介绍如何测试硬盘,RAID,SAN,SSD,云硬盘等,然后再来回答上面的问题。测试前提
我们在进行测试时,都会分清楚:- 测试对象:要区分硬盘、SSD、RAID、SAN、云硬盘等,因为它们有不同的特点
- 测试指标:IOPS和MBPS(吞吐率),下面会具体阐述
- 测试工具:Linux下常用Fio、dd工具, Windows下常用IOMeter,
- 测试参数: IO大小,寻址空间,队列深度,读写模式,随机/顺序模式
- 测试方法:也就是测试步骤。
存储系统模型
为了更好的测试,我们需要先了解存储系统,块存储系统本质是一个排队模型,我们可以拿银行作为比喻。还记得你去银行办事时的流程吗?- 去前台取单号
- 等待排在你之前的人办完业务
- 轮到你去某个柜台
- 柜台职员帮你办完手续1
- 柜台职员帮你办完手续2
- 柜台职员帮你办完手续3
- 办完业务,从柜台离开
- 服务时间 = 手续1 + 手续2 + 手续3
- 响应时间 = 服务时间 + 等待时间
- 性能 = 单位时间内处理业务数量
- 增加柜台数
- 降低服务时间
- 增加并行度
- 降低服务时间
硬盘测试
硬盘原理
我们应该如何测试SATA/SAS硬盘呢?首先需要了解磁盘的构造,并了解磁盘的工作方式:![harddisk](https://www.ustack.com/wp-content/uploads/2014/09/harddisk.jpg)
- 收到IO请求,得到地址和数据大小
- 移动磁头(寻址)
- 找到相应的磁道(寻址)
- 读取数据
- 传输数据
使用dd测试硬盘
虽然硬盘的性能是可以估算出来的,但是怎么才能让应用获得这些性能呢?对于测试工具来说,就是如何得到IOPS和MBPS峰值。我们先用dd测试一下SATA硬盘的MBPS(吞吐量)。#dd if=/dev/zero of=/dev/sdd bs=4k count=300000 oflag=direct
记录了300000+0 的读入 记录了300000+0 的写出 1228800000字节(1.2 GB)已复制,17.958 秒,68.4 MB/秒
#iostat -x sdd 5 10 ... Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sdd 0.00 0.00 0.00 16794.80 0.00 134358.40 8.00 0.79 0.05 0.05 78.82 ...为什么这块硬盘的MBPS只有68MB/s? 这是因为磁盘利用率是78%,没有到达95%以上,还有部分时间是空闲的。当dd在前一个IO响应之后,在准备发起下一个IO时,SATA硬盘是空闲的。那么如何才能提高利用率,让磁盘不空闲呢?只有一个办法,那就是增加硬盘的队列深度。相对于CPU来说,硬盘属于慢速设备,所有操作系统会有给每个硬盘分配一个专门的队列用于缓冲IO请求。
队列深度
什么是磁盘的队列深度?在某个时刻,有N个inflight的IO请求,包括在队列中的IO请求、磁盘正在处理的IO请求。N就是队列深度。加大硬盘队列深度就是让硬盘不断工作,减少硬盘的空闲时间。
加大队列深度 -> 提高利用率 -> 获得IOPS和MBPS峰值 -> 注意响应时间在可接受的范围内增加队列深度的办法有很多
- 使用异步IO,同时发起多个IO请求,相当于队列中有多个IO请求
- 多线程发起同步IO请求,相当于队列中有多个IO请求
- 增大应用IO大小,到达底层之后,会变成多个IO请求,相当于队列中有多个IO请求 队列深度增加了。
dd if=/dev/zero of=/dev/sdd bs=2M count=1000 oflag=direct
记录了1000+0 的读入 记录了1000+0 的写出 2097152000字节(2.1 GB)已复制,10.6663 秒,197 MB/秒
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sdd 0.00 0.00 0.00 380.60 0.00 389734.40 1024.00 2.39 6.28 2.56 97.42可以看到2MB的IO到达底层之后,会变成多个512KB的IO,平均队列长度为2.39,这个硬盘的利用率是97%,MBPS达到了197MB/s。(为什么会变成512KB的IO,你可以去使用Google去查一下内核参数 max_sectors_kb的意义和使用方法 ) 也就是说增加队列深度,是可以测试出硬盘的峰值的。
使用fio测试硬盘
现在,我们来测试下SATA硬盘的4KB随机写的IOPS。因为我的环境是Linux,所以我使用FIO来测试。$fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=1000G -filename=/dev/vdb -name="EBS 4K randwrite test" -iodepth=64 -runtime=60简单介绍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: 测试时长
![qq-stat-iops-1](https://www.ustack.com/wp-content/uploads/2014/09/qq-stat-iops-1.jpg)
![qq-stat-iops-4](https://www.ustack.com/wp-content/uploads/2014/09/qq-stat-iops-4.jpg)
队列深度 | IOPS | 平均响应时间 |
1 | 332.931525 | 3.002217 |
2 | 333.985074 | 5.986528 |
4 | 332.594653 | 12.025060 |
8 | 336.568012 | 23.766359 |
16 | 329.785606 | 48.513477 |
32 | 332.054590 | 96.353934 |
64 | 331.041063 | 193.200815 |
128 | 331.309109 | 385.163111 |
256 | 327.442963 | 774.401781 |
寻址空间对IOPS的影响
我们继续测试SATA硬盘,前面我们提到寻址空间参数也会对IOPS产生影响,下面我们就测试当size=1GB时的情况。![qq-stat-iops-1gb](https://www.ustack.com/wp-content/uploads/2014/09/qq-stat-iops-1gb.jpg)
硬盘优化
硬盘厂商提高硬盘性能的方法主要是降低服务时间(延迟):- 提高转速(降低旋转时间和传输时间)
- 增加Cache(降低写延迟,但不会提高IOPS)
- 提高单磁道密度(变相提高传输时间)
RAID测试
RAID0/RAID5/RAID6的多块磁盘可以同时服务,其实就是提高并行度,这样极大提高了性能(相当于银行有多个柜台)。 以前测试过12块RAID0,100GB的寻址空间,4KB随机写,逐步提高队列深度,IOPS会提高,因为它有12块磁盘(12个磁头同时工作),并行度是12。队列深度 | IOPS | 平均响应时间 |
1 | 1215.995842 | 0.820917 |
2 | 4657.061317 | 0.428420 |
4 | 5369.326970 | 0.744060 |
8 | 5377.387303 | 1.486629 |
16 | 5487.911660 | 2.914048 |
32 | 5470.972663 | 5.846616 |
64 | 5520.234015 | 11.585251 |
128 | 5542.739816 | 23.085843 |
256 | 5513.994611 | 46.401606 |
- 使用大内存Cache
- 使用IO处理器,降低XOR操作的延迟。
- 使用更大带宽的硬盘接口
SAN测试
对于低端磁盘阵列,使用单机IOmeter就可以测试出它的IOPS和MBPS的峰值,但是对于高端磁盘阵列,就需要多机并行测试才能得到IOPS和MBPS的峰值(IOmeter支持多机并行测试)。下图是纪念照。![huawei-highend-san](https://www.ustack.com/wp-content/uploads/2014/09/huawei-highend-san.jpg)
- 更快的存储网络,比如FC和IB,延时更低。
- 读写Cache。写数据到Cache之后就马上返回,不需要落盘。 而且磁盘阵列有更多的控制器和硬盘,大大提高了并行度。
SSD测试
SSD的延时很低,并行度很高(多个nand块同时工作),缺点是寿命和GC造成的响应时间不稳定。![ssd](https://www.ustack.com/wp-content/uploads/2014/09/ssd.jpg)
![samsung_ssd_840_pro_512gb_preconditioning_4kwrite_maxlatency(1)](https://www.ustack.com/wp-content/uploads/2014/09/samsung_ssd_840_pro_512gb_preconditioning_4kwrite_maxlatency1.png)
云硬盘测试
我们通过两方面来提高云硬盘的性能的:- 降低延迟(使用SSD,使用万兆网络,优化代码,减少瓶颈)
- 提高并行度(数据分片,同时使用整个集群的所有SSD)
在Linux下测试云硬盘
在Linux下,你可以使用FIO来测试
- 操作系统:Ubuntu 14.04
- CPU: 2
- Memory: 2GB
- 云硬盘大小: 1TB(SLA: 6000 IOPS, 170MB/s吞吐率 )
#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
![qq-ebs-iops-4k-w](https://www.ustack.com/wp-content/uploads/2014/09/qq-ebs-iops-4k-w.jpg)
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
![qq-ebs-iops-4k-r](https://www.ustack.com/wp-content/uploads/2014/09/qq-ebs-iops-4k-r.jpg)
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
![qq-win2012-setting](https://www.ustack.com/wp-content/uploads/2014/09/qq-win2012-setting.jpg)
4K随机写测试
打开IOMeter(你需要先 下载),你会看到IOMeter的主界面。在右边,你回发现4个worker(数量和CPU个数相同),因为我们现在只需要1个worker,所以你需要把其他3个worker移除掉。![qq-iomter-ui](https://www.ustack.com/wp-content/uploads/2014/09/qq-iomter-ui.jpg)
![qq-iometer-options-01](https://www.ustack.com/wp-content/uploads/2014/09/qq-iometer-options-01.jpg)
然后在测试集中选择"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处理逻辑
128MB/s VS 170MB/s
回到最开始的问题 "为什么使用dd命令测试云硬盘只有128MB/s", 这是因为目前云硬盘在处理超大IO请求时的延迟比SSD高(我们会不断进行优化),现在我们有两种方法来获得更高的MBPS:- 设置max_sectors_kb为256 (系统默认为512),降低延迟
- 使用fio来测试,加大队列深度
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的吞吐率。
![qq-ebs-mbps-512kb](https://www.ustack.com/wp-content/uploads/2014/09/qq-ebs-mbps-512kb1.jpg)
不可测试的指标
IOPS和MBPS是用户可以使用工具测试的指标,云硬盘还有一些用户不可测量的指标- 数据一致性
- 数据持久性
- 数据可用性
总结
上面介绍了一下测试工具和一些观点,希望对你有所帮助。
- 测试需要定性和定量
- 了解存储模型可以帮助你更好的进行测试
- 增加队列深度可以有效测试出IOPS和MBPS的峰值