一、概念介绍：

磁盘性能指标--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 请求所花费的时间，
它由寻道时间、旋转延迟和数据传输时间三部分构成：
1) 寻道时间 Tseek 是指将读写磁头移动至正确的磁道上所需要的时间。寻道时间越短，I/O
操作越快，目前磁盘的平均寻道时间一般在 3－15ms。
2) 旋转延迟 Trotation 是指盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间。
旋转延迟取决于磁盘转速，通常使用磁盘旋转一周所需时间的 1/2 表示。比如，7200 rpm 的
磁盘平均旋转延迟大约为 60*1000/7200/2 = 4.17ms，而转速为 15000 rpm 的磁盘其平均旋转
延迟为 2ms。
3) 数据传输时间 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
办完业务，从柜台离开
如何评估银行的效率呢：
服务时间 = 手续 1 + 手续 2 + 手续 3
响应时间 = 服务时间 + 等待时间
性能 = 单位时间内处理业务数量

那银行如何提高效率呢:
增加柜台数
降低服务时间
因此，排队系统或存储系统的优化方法是
增加并行度
降低服务时间

硬盘测试
硬盘原理
每个硬盘都有一个磁头(相当于银行的柜台)，硬盘的工作方式是：
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 峰值 -> 注意响应时间在可接受的范围
内
增加队列深度的办法有很多
1) 使用异步 IO，同时发起多个 IO 请求，相当于队列中有多个 IO 请求
2) 多线程发起同步 IO 请求，相当于队列中有多个 IO 请求
3) 增大应用 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 的意义和使用方法)。也就是说增加队列深度，是
可以测试出硬盘的峰值的。
现在，我们来测试下 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 的情况。

1) iodepth = 1 的测试结果。
上图中蓝色方框里面的是测出的 IOPS 230, 绿色方框里面是每个 IO 请求的平均响应时间，
大约是 4.3ms。***方框表示 95%的 IO 请求的响应时间是小于等于 9.920 ms。橙色方框表示
该硬盘的利用率已经达到了 98.58%。

2) iodepth = 4 的测试:
我们发现这次测试的 IOPS 没有提高，反而 IO 平均响应时间变大了，是 17ms。
为什么这里提高队列深度没有作用呢，原因当队列深度为 1 时，硬盘的利用率已经达到了
98%，说明硬盘已经没有多少空闲时间可以压榨了。而且响应时间为 4ms。 对于 SATA 硬盘，
当增加队列深度时，并不会增加 IOPS，只会增加响应时间。这是因为硬盘只有一个磁头，
并行度是 1， 所以当 IO 请求队列变长时，每个 IO 请求的等待时间都会变长，导致响应时
间也变长。

这是以前用 IOMeter 测试一块 SATA 硬盘的 4K 随机写性能，可以看到 IOPS 不会随着队列

深度的增加而增加，反而是平均响应时间在倍增。
队列深度 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 时的情况。

我们发现，当设置 size=1GB 时，IOPS 会显著提高到 568，IO 平均响应时间会降到 7ms(队

列深度为 4)。这是因为当寻址空间为 1GB 时，磁头需要移动的距离变小了，每次 IO 请求的
服务时间就降低了，这就是空间局部性原理。假如我们测试的 RAID 卡或者是磁盘阵列
(SAN)，它们可能会用 Cache 把这 1GB 的数据全部缓存，极大降低了 IO 请求的服务时间
(内存的写操作比硬盘的写操作快很 1000 倍)。所以设置寻址空间为 1GB 的意义不大，因为
我们是要测试硬盘的全盘性能，而不是 Cache 的性能。

硬盘优化
硬盘厂商提高硬盘性能的方法主要是降低服务时间(延迟)：
提高转速(降低旋转时间和传输时间)
增加 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

RAID 卡厂商优化的方法也是降低服务时间：
1) 使用大内存 Cache
2) 使用 IO 处理器，降低 XOR 操作的延迟。
3) 使用更大带宽的硬盘接口

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

磁盘阵列厂商通过以下手段降低服务时间：
1) 更快的存储网络，比如 FC 和 IB，延时更低。
2) 读写 Cache。写数据到 Cache 之后就马上返回，不需要落盘。 而且磁盘阵列有更多的控
制器和硬盘，大大提高了并行度。

现在的存储厂商会找 SPC 帮忙测试自己的磁盘阵列产品(或全闪存阵列)， 并给 SPC 支付费

用，这就是赤裸裸的标准垄断。国内也有做存储系统测试的，假如你要测试磁盘阵列，可
以找 NSTC (广告时间)。
SSD 测试
SSD 的延时很低，并行度很高(多个 nand 块同时工作)，缺点是寿命和 GC 造成的响应时间
不稳定。
推荐用 IOMeter 进行测试，使用大队列深度，并进行长时间测试，这样可以测试出 SSD 的
真实性能。

下图是 storagereview 对一些 SSD 硬盘做的 4KB 随机写的长时间测试，可以看出有些 SSD

硬盘的最大响应时间很不稳定，会飙高到几百 ms，这是不可接受的。