磁盘性能指标-ag真人游戏

一、概念介绍：

磁盘性能指标--iops
----------------------------------------------------------
        iops (input/output per second)即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。iops是指单位时间内系统能处理的i/o请求数量，一般以每秒处理的i/o请求数量为单位，i/o请求通常为读或写数据操作请求。

    随机读写频繁的应用，如小文件存储(图片)、oltp数据库、邮件服务器，关注随机读写性能，iops是关键衡量指标。
    顺序读写频繁的应用，传输大量连续数据，如电视台的视频编辑，视频点播vod(video on demand)，关注连续读写性能。数据吞吐量是关键衡量指标。

iops和数据吞吐量适用于不同的场合：
读取10000个1kb文件，用时10秒  throught(吞吐量)=1mb/s ，iops=1000  追求iops
读取1个10mb文件，用时0.2秒  throught(吞吐量)=50mb/s, iops=5  追求吞吐量

磁盘服务时间
--------------------------------------
传统磁盘本质上一种机械装置，如fc, sas, sata磁盘，转速通常为5400/7200/10k/15k rpm不等。影响磁盘的关键因素是磁盘服务时间，即磁盘完成一个i/o请求所花费的时间，它由寻道时间、旋转延迟和数据传输时间三部分构成。

寻道时间 tseek是指将读写磁头移动至正确的磁道上所需要的时间。寻道时间越短，i/o操作越快，目前磁盘的平均寻道时间一般在3－15ms。
旋转延迟 trotation是指盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间。旋转延迟取决于磁盘转速，通常使用磁盘旋转一周所需时间的1/2表示。比如，7200 rpm的磁盘平均旋转延迟大约为60*1000/7200/2 = 4.17ms，而转速为15000 rpm的磁盘其平均旋转延迟为2ms。
数据传输时间 ttransfer是指完成传输所请求的数据所需要的时间，它取决于数据传输率，其值等于数据大小除以数据传输率。目前ide/ata能达到133mb/s，sata ii可达到300mb/s的接口数据传输率，数据传输时间通常远小于前两部分消耗时间。简单计算时可忽略。

常见磁盘平均物理寻道时间为：
7200转/分的stat硬盘平均物理寻道时间是9ms
10000转/分的stat硬盘平均物理寻道时间是6ms
15000转/分的sas硬盘平均物理寻道时间是4ms

常见硬盘的旋转延迟时间为：

7200  rpm的磁盘平均旋转延迟大约为60*1000/7200/2 = 4.17ms

10000 rpm的磁盘平均旋转延迟大约为60*1000/10000/2 = 3ms，

15000 rpm的磁盘其平均旋转延迟约为60*1000/15000/2 = 2ms。

最大iops的理论计算方法
--------------------------------------
iops = 1000 ms/ (寻道时间 旋转延迟)。可以忽略数据传输时间。

7200  rpm的磁盘iops = 1000 / (9 4.17)  = 76 iops
10000 rpm的磁盘iops = 1000 / (6 3) = 111 iops
15000 rpm的磁盘iops = 1000 / (4 2) = 166 iops

影响测试的因素
-----------------------------------------
实际测量中，iops数值会受到很多因素的影响，包括i/o负载特征(读写比例，顺序和随机，工作线程数，队列深度，数据记录大小)、系统配置、操作系统、磁盘驱动等等。因此对比测量磁盘iops时，必须在同样的测试基准下进行，即便如此也会产生一定的随机不确定性。

队列深度说明 
ncq、scsi tcq、pata tcq和sata tcq技术解析 
----------------------------------------
    是一种命令排序技术，一把喂给设备更多的io请求，让电梯算法和设备有机会来安排合并以及内部并行处理，提高总体效率。
scsi tcq的队列深度支持256级
ata tcq的队列深度支持32级 （需要8m以上的缓存）
ncq最高可以支持命令深度级数为32级，ncq可以最多对32个命令指令进行排序。
    大多数的软件都是属于同步i/o软件，也就是说程序的一次i/o要等到上次i/o操作的完成后才进行，这样在硬盘中同时可能仅只有一个命令，也是无法发挥这个技术的优势，这时队列深度为1。
    随着intel的超线程技术的普及和应用环境的多任务化，以及异步i/o软件的大量涌现。这项技术可以被应用到了，实际队列深度的增加代表着性能的提高。
在测试时，队列深度为1是主要指标，大多数时候都参考1就可以。实际运行时队列深度也一般不会超过4.

iops可细分为如下几个指标：
-----------------------------------------
数据量为n字节，队列深度为k时，随机读取的iops
数据量为n字节，队列深度为k时，随机写入的iops

二、举例测试：

uos公有云开放以来，一些用户反应用dd命令测试出来的1tb云硬盘的吞吐率(mbps)只有128mb/s，而不是我们sla保证的170mb /s ，这是为什么？下面我会简单介绍如何测试硬盘，raid，san，ssd，云硬盘等，然后再来回答上面的问题。

我们在进行测试时，都会分清楚:

• 测试对象：要区分硬盘、ssd、raid、san、云硬盘等，因为它们有不同的特点

• 测试指标：iops和mbps(吞吐率)，下面会具体阐述

• 测试工具：linux下常用fio、dd工具,  windows下常用iometer,

• 测试参数:  io大小，寻址空间，队列深度，读写模式，随机/顺序模式

• 测试方法：也就是测试步骤。

测试是为了对比，所以需要定性和定量。在宣布自己的测试结果时，需要说明这次测试的工具、参数、方法，以便于比较。

测试工具 fio:

顺序读

测试命令:fio -name iops -rw=read -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda6 -ioengine libaio -direct=1

sata
jobs: 1 (f=1): [r] [16.4% done] [124.1m/0k /s] [31.3k/0  iops] [eta 00m:51s]
sas
jobs: 1 (f=1): [r] [16.4% done] [190m/0k /s] [41.3k/0  iops] [eta 00m:51s]
ssd
jobs: 1 (f=1): [r] [100.0% done] [404m/0k /s] [103k /0  iops] [eta 00m:00s]

可以看到 在对4kb数据包进行连续读的情况下:

ssd其速度可以达到404mb/s，iops达到103k/s

sas其速度可以达到190mb/s，iops达到41k/s

sata其速度可以达到124mb/s，iops达到31k/s

顺序读，sas总体表现是sata硬盘的1.3倍，ssd总体表现是sata硬盘的4倍。

随机读

测试命令 fio -name iops -rw=randread -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda6 -ioengine libaio -direct=1

sata
jobs: 1 (f=1): [r] [41.0% done] [466k/0k /s] [114 /0  iops] [eta 00m:36s]
sas
jobs: 1 (f=1): [r] [41.0% done] [1784k/0k /s] [456 /0  iops] [eta 00m:36s]
ssd
jobs: 1 (f=1): [r] [100.0% done] [505m/0k /s] [129k /0  iops] [eta 00m:00s]

随机读，sas总体表现是sata硬盘的4倍，ssd总体表现是sata硬盘的一千多倍。

顺序写

测试命令:fio -name iops -rw=write -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda6 -ioengine libaio -direct=1

sata
jobs: 1 (f=1): [w] [21.3% done] [0k/124.9m /s] [0 /31.3k iops] [eta 00m:48s]
sas
jobs: 1 (f=1): [w] [21.3% done] [0k/190m /s] [0 /36.3k iops] [eta 00m:48s]
ssd
jobs: 1 (f=1): [w] [100.0% done] [0k/592m /s] [0 /152k  iops] [eta 00m:00s]

同样的4kb数据包顺序写的情况下，ssd卡的成绩为592mb/s，iops为152k。而本地硬盘仅为118mb/s，iops仅为30290。

随机写

测试命令: fio -name iops -rw=randwrite -bs=4k -runtime=60 -iodepth 32 -filename /dev/sda6 -ioengine libaio -direct=1

sata
jobs: 1 (f=1): [w] [100.0% done] [0k/548k /s] [0 /134  iops] [eta 00m:00s]
sas
jobs: 1 (f=1): [w] [100.0% done] [0k/2000k /s] [0 /512  iops] [eta 00m:00s]
ssd
jobs: 1 (f=1): [w] [100.0% done] [0k/549m /s] [0 /140k  iops] [eta 00m:00s]

在接下来的4kb数据包随机写操作中，ssd卡再次展示了其高超的io性能，高达549mb/s的随机写速率，iops高达140k。相比之下，本地硬盘的随机读写仅为548kb/s，iops为134。

为了更好的测试，我们需要先了解存储系统，块存储系统本质是一个排队模型，我们可以拿银行作为比喻。还记得你去银行办事时的流程吗？

1. 去前台取单号

2. 等待排在你之前的人办完业务

3. 轮到你去某个柜台

4. 柜台职员帮你办完手续1

5. 柜台职员帮你办完手续2

6. 柜台职员帮你办完手续3

7. 办完业务，从柜台离开

如何评估银行的效率呢：

• 服务时间 = 手续1 手续2 手续3

• 响应时间 = 服务时间 等待时间

• 性能 = 单位时间内处理业务数量

那银行如何提高效率呢:

• 增加柜台数

• 降低服务时间

因此，排队系统或存储系统的优化方法是

• 增加并行度

• 降低服务时间

硬盘原理

我们应该如何测试sata/sas硬盘呢？

每个硬盘都有一个磁头(相当于银行的柜台)，硬盘的工作方式是：

1. 收到io请求，得到地址和数据大小

2. 移动磁头(寻址)

3. 找到相应的磁道(寻址)

4. 读取数据

5. 传输数据

则磁盘的随机io服务时间:

服务时间 = 寻道时间 旋转时间 传输时间

对于10000转速的sata硬盘来说，一般寻道时间是7 ms，旋转时间是3 ms, 64kb的传输时间是 0.8 ms， 则sata硬盘每秒可以进行随机io操作是 1000/(7 3 0.8) = 93，所以我们估算sata硬盘64kb随机写的iops是93。一般的硬盘厂商都会标明顺序读写的mbps。

我们在列出iops时，需要说明io大小，寻址空间，读写模式，顺序/随机，队列深度。我们一般常用的io大小是4kb，这是因为文件系统常用的块大小是4kb。

使用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请求 队列深度增加了。

队列深度增加了，io在队列的等待时间也会增加，导致io响应时间变大，这需要权衡。让我们通过增加io大小来增加dd的队列深度，看有没有效果：

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: 测试时长

下面我们做两次测试，分别 iodepth = 1和iodepth = 4的情况。下面是iodepth = 1的测试结果。

上图中蓝色方框里面的是测出的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不会随着队列深度的增加而增加，反而是平均响应时间在倍增。

寻址空间对iops的影响

我们继续测试sata硬盘，前面我们提到寻址空间参数也会对iops产生影响，下面我们就测试当size=1gb时的情况。

我们发现，当设置size=1gb时，iops会显著提高到568，io平均响应时间会降到7ms(队列深度为4)。这是因为当寻址空间为1gb时，磁头需要移动的距离变小了，每次io请求的服务时间就降低了，这就是空间局部性原理。假如我们测试的raid卡或者是磁盘阵列(san)，它们可能会用cache把这1gb的数据全部缓存，极大降低了io请求的服务时间(内存的写操作比硬盘的写操作快很1000倍)。所以设置寻址空间为1gb的意义不大，因为我们是要测试硬盘的全盘性能，而不是cache的性能。

硬盘优化

硬盘厂商提高硬盘性能的方法主要是降低服务时间(延迟)：

• 提高转速(降低旋转时间和传输时间)

• 增加cache(降低写延迟，但不会提高iops)

• 提高单磁道密度(变相提高传输时间)

raid0/raid5/raid6的多块磁盘可以同时服务，其实就是提高并行度，这样极大提高了性能(相当于银行有多个柜台)。

以前测试过12块raid0，100gb的寻址空间，4kb随机写，逐步提高队列深度，iops会提高，因为它有12块磁盘(12个磁头同时工作)，并行度是12。

raid卡厂商优化的方法也是降低服务时间：

• 使用大内存cache

• 使用io处理器，降低xor操作的延迟。

• 使用更大带宽的硬盘接口

对于低端磁盘阵列，使用单机iometer就可以测试出它的iops和mbps的峰值，但是对于高端磁盘阵列，就需要多机并行测试才能得到iops和mbps的峰值(iometer支持多机并行测试)。

磁盘阵列厂商通过以下手段降低服务时间：

1. 更快的存储网络，比如fc和ib，延时更低。

2. 读写cache。写数据到cache之后就马上返回，不需要落盘。 而且磁盘阵列有更多的控制器和硬盘，大大提高了并行度。

现在的存储厂商会找spc帮忙测试自己的磁盘阵列产品(或全闪存阵列)， 并给spc支付费用，这就是赤裸裸的标准垄断。国内也有做存储系统测试的，假如你要测试磁盘阵列，可以找nstc (广告时间)。

ssd的延时很低，并行度很高(多个nand块同时工作)，缺点是寿命和gc造成的响应时间不稳定。

推荐用iometer进行测试，使用大队列深度，并进行长时间测试，这样可以测试出ssd的真实性能。

下图是storagereview对一些ssd硬盘做的4kb随机写的长时间测试，可以看出有些ssd硬盘的最大响应时间很不稳定，会飙高到几百ms，这是不可接受的。

我们通过两方面来提高云硬盘的性能的：

1. 降低延迟(使用ssd，使用万兆网络，优化代码，减少瓶颈)

2. 提高并行度(数据分片，同时使用整个集群的所有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格式的测试结果。

顺序读写测试

我们再按照上面的步骤，进行了顺序读/写测试。下面是测试结果：

当前云硬盘写操作的主要延迟是

1. 网络传输

2. 多副本，写三份(数据强一致性)

3. 三份数据都落盘(数据持久化)之后，才返回

4. io处理逻辑

我们当前主要是优化io处理逻辑，并没有去优化2和3，这是因为我们是把用户数据的安全性放在第一位。

回到最开始的问题 “为什么使用dd命令测试云硬盘只有128mb/s”， 这是因为目前云硬盘在处理超大io请求时的延迟比ssd高(我们会不断进行优化)，现在我们有两种方法来获得更高的mbps：

1. 设置max_sectors_kb为256 (系统默认为512)，降低延迟

2. 使用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是用户可以使用工具测试的指标，云硬盘还有一些用户不可测量的指标

1. 数据一致性

2. 数据持久性

3. 数据可用性

这些指标我们只能通过根据系统架构和约束条件计算得到，然后转告给用户。这些指标衡量着公有云厂商的良心，有机会会专门进行介绍。

上面介绍了一下测试工具和一些观点，希望对你有所帮助。

• 测试需要定性和定量

• 了解存储模型可以帮助你更好的进行测试

• 增加队列深度可以有效测试出iops和mbps的峰值