IO系统衡量性能的几个指标
作为一个数据库管理员，关注系统的性能是日常最重要的工作之一，而在所关注的各方面的性能只能io性能却是最令人头痛的一块，面对着各种生涩的参数和令人眼花缭乱的新奇的术语，再加上存储厂商的忽悠，总是让我们有种云里雾里的感觉。本系列文章试图从基本概念开始对磁盘存储相关的各种概念进行综合归纳，让大家能够对io性能相关的基本概念，io性能的监控和调整有个比较全面的了解。
在这一部分里我们先舍弃各种结构复杂的存储系统，直接研究一个单独的磁盘的性能问题，藉此了解各个衡量io系统系能的各个指标以及之间的关系。需要注意的是，本文探讨的仅限于磁盘io性能，网络io性能不考虑在内。
几个基本的概念
在研究磁盘性能之前我们必须先了解磁盘的结构，以及工作原理。不过在这里就不再重复说明了，关系硬盘结构和工作原理的信息可以参考维基百科上面的相关词条——hard disk drive(英文)和硬盘驱动器(中文)。
读写io(read/write io)操作
磁盘是用来给我们存取数据用的，因此当说到io操作的时候，就会存在两种相对应的操作，存数据时候对应的是写io操作，取数据的时候对应的是是读io操作。
单个io操作
当控制磁盘的控制器接到操作系统的读io操作指令的时候，控制器就会给磁盘发出一个读数据的指令，并同时将要读取的数据块的地址传递给磁盘，然后磁盘会将读取到的数据传给控制器，并由控制器返回给操作系统，完成一个写io的操作;同样的，一个写io的操作也类似，控制器接到写的io操作的指令和要写入的数据，并将其传递给磁盘，磁盘在数据写入完成之后将操作结果传递回控制器，再由控制器返回给操作系统，完成一个写io的操作。单个io操作指的就是完成一个写io或者是读io的操作。
随机访问(random access)与连续访问(sequential access)
随机访问指的是本次io所给出的扇区地址和上次io给出扇区地址相差比较大，这样的话磁头在两次io操作之间需要作比较大的移动动作才能重新开始读/写数据。相反的，如果当次io给出的扇区地址与上次io结束的扇区地址一致或者是接近的话，那磁头就能很快的开始这次io操作，这样的多个io操作称为连续访问。因此尽管相邻的两次io操作在同一时刻发出，但如果它们的请求的扇区地址相差很大的话也只能称为随机访问，而非连续访问。
顺序io模式(queue mode)/并发io模式(burst mode)
磁盘控制器可能会一次对磁盘组发出一连串的io命令，如果磁盘组一次只能执行一个io命令时称为顺序io;当磁盘组能同时执行多个io命令时，称为并发io。并发io只能发生在由多个磁盘组成的磁盘组上，单块磁盘只能一次处理一个io命令。
第2页：单个io的大小(io chunk size)
单个io的大小(io chunk size)
熟悉数据库的人都会有这么一个概念，那就是数据库存储有个基本的块大小(block size)，不管是sql server还是oracle，默认的块大小都是8kb，就是数据库每次读写都是以8k为单位的。那么对于数据库应用发出的固定8k大小的单次读写到了写磁盘这个层面会是怎么样的呢，就是对于读写磁盘来说单个io操作操作数据的大小是多少呢，是不是也是一个固定的值?
答案是不确定。首先操作系统为了提高 io的性能而引入了文件系统缓存(file system cache)，系统会根据请求数据的情况将多个来自io的请求先放在缓存里面，然后再一次性的提交给磁盘，也就是说对于数据库发出的多个8k数据块的读操作有可能放在一个磁盘读io里就处理了。
还有对于有些存储系统也是提供了缓存(cache)的，接收到操作系统的io请求之后也是会将多个操作系统的 io请求合并成一个来处理。不管是操作系统层面的缓存还是磁盘控制器层面的缓存，目的都只有一个，提高数据读写的效率。因此每次单独的io操作大小都是不一样的，它主要取决于系统对于数据读写效率的判断。
当一次io操作大小比较小的时候我们成为小的io操作，比如说1k，4k，8k这样的;当一次io操作的数据量比较的的时候称为大io操作，比如说32k，64k甚至更大。
在我们说到块大小(block size)的时候通常我们会接触到多个类似的概念，像我们上面提到的那个在数据库里面的数据最小的管理单位，oralce称之为块(block)，大小一般为8k，sql server称之为页(page)，一般大小也为8k。
在文件系统里面我们也能碰到一个文件系统的块，在现在很多的linux系统中都是4k(通过 /usr/bin/time -v可以看到)，它的作用其实跟数据库里面的块/页是一样的，都是为了方便数据的管理。但是说到单次io的大小，跟这些块的大小都是没有直接关系的，在英文里单次io大小通常被称为是io chunk size，不会说成是io block size的。
第3页：iops(io per second)
iops(io per second)
iops，io系统每秒所执行io操作的次数，是一个重要的用来衡量系统io能力的一个参数。对于单个磁盘组成的io系统来说，计算它的iops不是一件很难的事情，只要我们知道了系统完成一次io所需要的时间的话我们就能推算出系统iops来。
现在我们就来推算一下磁盘的iops，假设磁盘的转速(rotational speed)为15k rpm，平均寻道时间为5ms，最大传输速率为40mb/s(这里将读写速度视为一样，实际会差别比较大)。
对于磁盘来说一个完整的io操作是这样进行的：当控制器对磁盘发出一个io操作命令的时候，磁盘的驱动臂(actuator arm)带读写磁头(head)离开着陆区(landing zone，位于内圈没有数据的区域)，移动到要操作的初始数据块所在的磁道(track)的正上方，这个过程被称为寻址(seeking)，对应消耗的时间被称为寻址时间(seek time);但是找到对应磁道还不能马上读取数据，这时候磁头要等到磁盘盘片(platter)旋转到初始数据块所在的扇区(sector)落在读写磁头正上方的之后才能开始读取数据，在这个等待盘片旋转到可操作扇区的过程中消耗的时间称为旋转延时(rotational delay);接下来就随着盘片的旋转，磁头不断的读/写相应的数据块，直到完成这次io所需要操作的全部数据，这个过程称为数据传送(data transfer)，对应的时间称为传送时间(transfer time)。完成这三个步骤之后一次io操作也就完成了。
在我们看硬盘厂商的宣传单的时候我们经常能看到3个参数，分别是平均寻址时间、盘片旋转速度以及最大传送速度，这三个参数就可以提供给我们计算上述三个步骤的时间。
第一个寻址时间，考虑到被读写的数据可能在磁盘的任意一个磁道，既有可能在磁盘的最内圈(寻址时间最短)，也可能在磁盘的最外圈(寻址时间最长)，所以在计算中我们只考虑平均寻址时间，也就是磁盘参数中标明的那个平均寻址时间，这里就采用当前最多的10krmp硬盘的5ms。
第二个旋转延时，和寻址一样，当磁头定位到磁道之后有可能正好在要读写扇区之上，这时候是不需要额外额延时就可以立刻读写到数据，但是最坏的情况确实要磁盘旋转整整一圈之后磁头才能读取到数据，所以这里我们也考虑的是平均旋转延时，对于10krpm的磁盘就是(60s/15k)*(1/2) = 2ms。
第三个传送时间，磁盘参数提供我们的最大的传输速度，当然要达到这种速度是很有难度的，但是这个速度却是磁盘纯读写磁盘的速度，因此只要给定了单次 io的大小，我们就知道磁盘需要花费多少时间在数据传送上，这个时间就是io chunk size / max transfer rate。
第4页：iops计算公式
iops计算公式
现在我们就可以得出这样的计算单次io时间的公式：
io time = seek time + 60 sec/rotational speed/2 + io chunk size/transfer rate
于是我们可以这样计算出iops
iops = 1/io time = 1/(seek time + 60 sec/rotational speed/2 + io chunk size/transfer rate)
对于给定不同的io大小我们可以得出下面的一系列的数据
4k (1/7.1 ms = 140 iops)
5ms + (60sec/15000rpm/2) + 4k/40mb = 5 + 2 + 0.1 = 7.1
8k (1/7.2 ms = 139 iops)
5ms + (60sec/15000rpm/2) + 8k/40mb = 5 + 2 + 0.2 = 7.2
16k (1/7.4 ms = 135 iops)
5ms + (60sec/15000rpm/2) + 16k/40mb = 5 + 2 + 0.4 = 7.4
32k (1/7.8 ms = 128 iops)
5ms + (60sec/15000rpm/2) + 32k/40mb = 5 + 2 + 0.8 = 7.8
64k (1/8.6 ms = 116 iops)
5ms + (60sec/15000rpm/2) + 64k/40mb = 5 + 2 + 1.6 = 8.6
从上面的数据可以看出，当单次io越小的时候，单次io所耗费的时间也越少，相应的iops也就越大。
上面我们的数据都是在一个比较理想的假设下得出来的，这里的理想的情况就是磁盘要花费平均大小的寻址时间和平均的旋转延时，这个假设其实是比较符合我们实际情况中的随机读写，在随机读写中，每次io操作的寻址时间和旋转延时都不能忽略不计，有了这两个时间的存在也就限制了iops的大小。现在我们考虑一种相对极端的顺序读写操作，比如说在读取一个很大的存储连续分布在磁盘的的文件，因为文件的存储的分布是连续的，磁头在完成一个读io操作之后，不需要从新的寻址，也不需要旋转延时，在这种情况下我们能到一个很大的iops值，如下
4k (1/0.1 ms = 10000 iops)
0ms + 0ms + 4k/40mb = 0.1
8k (1/0.2 ms = 5000 iops)
0ms + 0ms + 8k/40mb = 0.2
16k (1/0.4 ms = 2500 iops)
0ms + 0ms + 16k/40mb = 0.4
32k (1/0.8 ms = 1250 iops)
0ms + 0ms + 32k/40mb = 0.8
64k (1/1.6 ms = 625 iops)
0ms + 0ms + 64k/40mb = 1.6
相比第一组数据来说差距是非常的大的，因此当我们要用iops来衡量一个io系统的系能的时候我们一定要说清楚是在什么情况的iops，也就是要说明读写的方式以及单次io的大小，当然在实际当中，特别是在oltp的系统的，随机的小io的读写是最有说服力的。
第5页：传输速度/吞吐率
传输速度(transfer rate)/吞吐率(throughput)
现在我们要说的传输速度(另一个常见的说法是吞吐率)不是磁盘上所表明的最大传输速度或者说理想传输速度，而是磁盘在实际使用的时候从磁盘系统总线上流过的数据量。有了iops数据之后我们是很容易就能计算出对应的传输速度来的
transfer rate = iops * io chunk size
还是那上面的第一组iops的数据我们可以得出相应的传输速度如下
4k: 140 * 4k = 560k / 40m = 1.36%
8k: 139 * 8k = 1112k / 40m = 2.71%
16k: 135 * 16k = 2160k / 40m = 5.27%
32k: 116 * 32k = 3712k / 40m = 9.06%
可以看出实际上的传输速度是很小的，对总线的利用率也是非常的小。
这里一定要明确一个概念，那就是尽管上面我们使用iops来计算传输速度，但是实际上传输速度和iops是没有直接关系，在没有缓存的情况下它们共同的决定因素都是对磁盘系统的访问方式以及单个io的大小。对磁盘进行随机访问时候我们可以利用iops来衡量一个磁盘系统的性能，此时的传输速度不会太大;但是当对磁盘进行连续访问时，此时的iops已经没有了参考的价值，这个时候限制实际传输速度却是磁盘的最大传输速度。因此在实际的应用当中，只会用iops来衡量小io的随机读写的性能，而当要衡量大io连续读写的性能的时候就要采用传输速度而不能是iops了。
第6页：io响应时间
io响应时间(io response time)
最后来关注一下能直接描述io性能的io响应时间。io响应时间也被称为io延时(io latency)，io响应时间就是从操作系统内核发出的一个读或者写的io命令到操作系统内核接收到io回应的时间，注意不要和单个io时间混淆了，单个io时间仅仅指的是io操作在磁盘内部处理的时间，而io响应时间还要包括io操作在io等待队列中所花费的等待时间。
计算io操作在等待队列里面消耗的时间有一个衍生于利托氏定理(little’s law)的排队模型m/m/1模型可以遵循，由于排队模型算法比较复杂，到现在还没有搞太明白(如果有谁对m/m/1模型比较精通的话欢迎给予指导)，这里就罗列一下最后的结果，还是那上面计算的iops数据来说：
8k io chunk size (135 iops, 7.2 ms)
135 => 240.0 ms
105 => 29.5 ms
75 => 15.7 ms
45 => 10.6 ms
64k io chunk size(116 iops, 8.6 ms)
135 => 没响应了……
105 => 88.6 ms
75 => 24.6 ms
45 => 14.6 ms
从上面的数据可以看出，随着系统实际iops越接近理论的最大值，io的响应时间会成非线性的增长，越是接近最大值，响应时间就变得越大，而且会比预期超出很多。一般来说在实际的应用中有一个70%的指导值，也就是说在io读写的队列中，当队列大小小于最大iops的70%的时候，io的响应时间增加会很小，相对来说让人比较能接受的，一旦超过70%，响应时间就会戏剧性的暴增，所以当一个系统的io压力超出最大可承受压力的70%的时候就是必须要考虑调整或升级了。
另外补充说一下这个70%的指导值也适用于cpu响应时间，这也是在实践中证明过的，一旦cpu超过70%，系统将会变得受不了的慢。很有意思的东西。
利用CAN总线实现煤矿安全监控传输系统的设计
苹果首个AR应用将会出现在iPhone8身上？还支持3D摄像？
苹果炮轰高通最终目的是想自己最基带芯片
CES2017：京津冀人民的神器！像防毒面具的防雾霾口罩
Modbus TCP通讯概述
IO系统衡量性能的几个指标
扬尘噪声在线监测系统解决方案
我国物联网成绩与挑战并存
浪潮存储深入研究数据需求，以不断提升数据价值
三星确认投资智能设备 可穿戴市场竞争加剧
“场景化造车”再出新款，北汽新能源加速产品攻势
小米11成功解决曲面屏误触问题
从颜控到技术宅 格兰仕普罗旺斯空调顺利俘获消费者
一种新型通信用整流器
AMD Ryzen评测,相比Intel八代酷睿,AMD略胜一筹
海尔云梦洗衣机闪亮登场，打造全球一流品牌
一个非常简单的家庭电话铃声发生器电路
DLT Support in CANape
声控开关带强启线的接线步骤
2010卡塔尔国际建筑、建材博览会/卡塔尔多哈建筑建材展/新
在这一部分里我们先舍弃各种结构复杂的存储系统，直接研究一个单独的磁盘的性能问题，藉此了解各个衡量io系统系能的各个指标以及之间的关系。需要注意的是，本文探讨的仅限于磁盘io性能，网络io性能不考虑在内。
几个基本的概念
在研究磁盘性能之前我们必须先了解磁盘的结构，以及工作原理。不过在这里就不再重复说明了，关系硬盘结构和工作原理的信息可以参考维基百科上面的相关词条——hard disk drive(英文)和硬盘驱动器(中文)。
读写io(read/write io)操作
磁盘是用来给我们存取数据用的，因此当说到io操作的时候，就会存在两种相对应的操作，存数据时候对应的是写io操作，取数据的时候对应的是是读io操作。
单个io操作
当控制磁盘的控制器接到操作系统的读io操作指令的时候，控制器就会给磁盘发出一个读数据的指令，并同时将要读取的数据块的地址传递给磁盘，然后磁盘会将读取到的数据传给控制器，并由控制器返回给操作系统，完成一个写io的操作;同样的，一个写io的操作也类似，控制器接到写的io操作的指令和要写入的数据，并将其传递给磁盘，磁盘在数据写入完成之后将操作结果传递回控制器，再由控制器返回给操作系统，完成一个写io的操作。单个io操作指的就是完成一个写io或者是读io的操作。
随机访问(random access)与连续访问(sequential access)
随机访问指的是本次io所给出的扇区地址和上次io给出扇区地址相差比较大，这样的话磁头在两次io操作之间需要作比较大的移动动作才能重新开始读/写数据。相反的，如果当次io给出的扇区地址与上次io结束的扇区地址一致或者是接近的话，那磁头就能很快的开始这次io操作，这样的多个io操作称为连续访问。因此尽管相邻的两次io操作在同一时刻发出，但如果它们的请求的扇区地址相差很大的话也只能称为随机访问，而非连续访问。
顺序io模式(queue mode)/并发io模式(burst mode)
磁盘控制器可能会一次对磁盘组发出一连串的io命令，如果磁盘组一次只能执行一个io命令时称为顺序io;当磁盘组能同时执行多个io命令时，称为并发io。并发io只能发生在由多个磁盘组成的磁盘组上，单块磁盘只能一次处理一个io命令。
第2页：单个io的大小(io chunk size)
单个io的大小(io chunk size)
熟悉数据库的人都会有这么一个概念，那就是数据库存储有个基本的块大小(block size)，不管是sql server还是oracle，默认的块大小都是8kb，就是数据库每次读写都是以8k为单位的。那么对于数据库应用发出的固定8k大小的单次读写到了写磁盘这个层面会是怎么样的呢，就是对于读写磁盘来说单个io操作操作数据的大小是多少呢，是不是也是一个固定的值?
答案是不确定。首先操作系统为了提高 io的性能而引入了文件系统缓存(file system cache)，系统会根据请求数据的情况将多个来自io的请求先放在缓存里面，然后再一次性的提交给磁盘，也就是说对于数据库发出的多个8k数据块的读操作有可能放在一个磁盘读io里就处理了。
还有对于有些存储系统也是提供了缓存(cache)的，接收到操作系统的io请求之后也是会将多个操作系统的 io请求合并成一个来处理。不管是操作系统层面的缓存还是磁盘控制器层面的缓存，目的都只有一个，提高数据读写的效率。因此每次单独的io操作大小都是不一样的，它主要取决于系统对于数据读写效率的判断。
当一次io操作大小比较小的时候我们成为小的io操作，比如说1k，4k，8k这样的;当一次io操作的数据量比较的的时候称为大io操作，比如说32k，64k甚至更大。
在我们说到块大小(block size)的时候通常我们会接触到多个类似的概念，像我们上面提到的那个在数据库里面的数据最小的管理单位，oralce称之为块(block)，大小一般为8k，sql server称之为页(page)，一般大小也为8k。
在文件系统里面我们也能碰到一个文件系统的块，在现在很多的linux系统中都是4k(通过 /usr/bin/time -v可以看到)，它的作用其实跟数据库里面的块/页是一样的，都是为了方便数据的管理。但是说到单次io的大小，跟这些块的大小都是没有直接关系的，在英文里单次io大小通常被称为是io chunk size，不会说成是io block size的。
第3页：iops(io per second)
iops(io per second)
iops，io系统每秒所执行io操作的次数，是一个重要的用来衡量系统io能力的一个参数。对于单个磁盘组成的io系统来说，计算它的iops不是一件很难的事情，只要我们知道了系统完成一次io所需要的时间的话我们就能推算出系统iops来。
现在我们就来推算一下磁盘的iops，假设磁盘的转速(rotational speed)为15k rpm，平均寻道时间为5ms，最大传输速率为40mb/s(这里将读写速度视为一样，实际会差别比较大)。
对于磁盘来说一个完整的io操作是这样进行的：当控制器对磁盘发出一个io操作命令的时候，磁盘的驱动臂(actuator arm)带读写磁头(head)离开着陆区(landing zone，位于内圈没有数据的区域)，移动到要操作的初始数据块所在的磁道(track)的正上方，这个过程被称为寻址(seeking)，对应消耗的时间被称为寻址时间(seek time);但是找到对应磁道还不能马上读取数据，这时候磁头要等到磁盘盘片(platter)旋转到初始数据块所在的扇区(sector)落在读写磁头正上方的之后才能开始读取数据，在这个等待盘片旋转到可操作扇区的过程中消耗的时间称为旋转延时(rotational delay);接下来就随着盘片的旋转，磁头不断的读/写相应的数据块，直到完成这次io所需要操作的全部数据，这个过程称为数据传送(data transfer)，对应的时间称为传送时间(transfer time)。完成这三个步骤之后一次io操作也就完成了。
在我们看硬盘厂商的宣传单的时候我们经常能看到3个参数，分别是平均寻址时间、盘片旋转速度以及最大传送速度，这三个参数就可以提供给我们计算上述三个步骤的时间。
第一个寻址时间，考虑到被读写的数据可能在磁盘的任意一个磁道，既有可能在磁盘的最内圈(寻址时间最短)，也可能在磁盘的最外圈(寻址时间最长)，所以在计算中我们只考虑平均寻址时间，也就是磁盘参数中标明的那个平均寻址时间，这里就采用当前最多的10krmp硬盘的5ms。
第二个旋转延时，和寻址一样，当磁头定位到磁道之后有可能正好在要读写扇区之上，这时候是不需要额外额延时就可以立刻读写到数据，但是最坏的情况确实要磁盘旋转整整一圈之后磁头才能读取到数据，所以这里我们也考虑的是平均旋转延时，对于10krpm的磁盘就是(60s/15k)*(1/2) = 2ms。
第三个传送时间，磁盘参数提供我们的最大的传输速度，当然要达到这种速度是很有难度的，但是这个速度却是磁盘纯读写磁盘的速度，因此只要给定了单次 io的大小，我们就知道磁盘需要花费多少时间在数据传送上，这个时间就是io chunk size / max transfer rate。
第4页：iops计算公式
iops计算公式
现在我们就可以得出这样的计算单次io时间的公式：
io time = seek time + 60 sec/rotational speed/2 + io chunk size/transfer rate
于是我们可以这样计算出iops
iops = 1/io time = 1/(seek time + 60 sec/rotational speed/2 + io chunk size/transfer rate)
对于给定不同的io大小我们可以得出下面的一系列的数据
4k (1/7.1 ms = 140 iops)
5ms + (60sec/15000rpm/2) + 4k/40mb = 5 + 2 + 0.1 = 7.1
8k (1/7.2 ms = 139 iops)
5ms + (60sec/15000rpm/2) + 8k/40mb = 5 + 2 + 0.2 = 7.2
16k (1/7.4 ms = 135 iops)
5ms + (60sec/15000rpm/2) + 16k/40mb = 5 + 2 + 0.4 = 7.4
32k (1/7.8 ms = 128 iops)
5ms + (60sec/15000rpm/2) + 32k/40mb = 5 + 2 + 0.8 = 7.8
64k (1/8.6 ms = 116 iops)
5ms + (60sec/15000rpm/2) + 64k/40mb = 5 + 2 + 1.6 = 8.6
从上面的数据可以看出，当单次io越小的时候，单次io所耗费的时间也越少，相应的iops也就越大。
上面我们的数据都是在一个比较理想的假设下得出来的，这里的理想的情况就是磁盘要花费平均大小的寻址时间和平均的旋转延时，这个假设其实是比较符合我们实际情况中的随机读写，在随机读写中，每次io操作的寻址时间和旋转延时都不能忽略不计，有了这两个时间的存在也就限制了iops的大小。现在我们考虑一种相对极端的顺序读写操作，比如说在读取一个很大的存储连续分布在磁盘的的文件，因为文件的存储的分布是连续的，磁头在完成一个读io操作之后，不需要从新的寻址，也不需要旋转延时，在这种情况下我们能到一个很大的iops值，如下
4k (1/0.1 ms = 10000 iops)
0ms + 0ms + 4k/40mb = 0.1
8k (1/0.2 ms = 5000 iops)
0ms + 0ms + 8k/40mb = 0.2
16k (1/0.4 ms = 2500 iops)
0ms + 0ms + 16k/40mb = 0.4
32k (1/0.8 ms = 1250 iops)
0ms + 0ms + 32k/40mb = 0.8
64k (1/1.6 ms = 625 iops)
0ms + 0ms + 64k/40mb = 1.6
相比第一组数据来说差距是非常的大的，因此当我们要用iops来衡量一个io系统的系能的时候我们一定要说清楚是在什么情况的iops，也就是要说明读写的方式以及单次io的大小，当然在实际当中，特别是在oltp的系统的，随机的小io的读写是最有说服力的。
第5页：传输速度/吞吐率
传输速度(transfer rate)/吞吐率(throughput)
现在我们要说的传输速度(另一个常见的说法是吞吐率)不是磁盘上所表明的最大传输速度或者说理想传输速度，而是磁盘在实际使用的时候从磁盘系统总线上流过的数据量。有了iops数据之后我们是很容易就能计算出对应的传输速度来的
transfer rate = iops * io chunk size
还是那上面的第一组iops的数据我们可以得出相应的传输速度如下
4k: 140 * 4k = 560k / 40m = 1.36%
8k: 139 * 8k = 1112k / 40m = 2.71%
16k: 135 * 16k = 2160k / 40m = 5.27%
32k: 116 * 32k = 3712k / 40m = 9.06%
可以看出实际上的传输速度是很小的，对总线的利用率也是非常的小。
这里一定要明确一个概念，那就是尽管上面我们使用iops来计算传输速度，但是实际上传输速度和iops是没有直接关系，在没有缓存的情况下它们共同的决定因素都是对磁盘系统的访问方式以及单个io的大小。对磁盘进行随机访问时候我们可以利用iops来衡量一个磁盘系统的性能，此时的传输速度不会太大;但是当对磁盘进行连续访问时，此时的iops已经没有了参考的价值，这个时候限制实际传输速度却是磁盘的最大传输速度。因此在实际的应用当中，只会用iops来衡量小io的随机读写的性能，而当要衡量大io连续读写的性能的时候就要采用传输速度而不能是iops了。
第6页：io响应时间
io响应时间(io response time)
最后来关注一下能直接描述io性能的io响应时间。io响应时间也被称为io延时(io latency)，io响应时间就是从操作系统内核发出的一个读或者写的io命令到操作系统内核接收到io回应的时间，注意不要和单个io时间混淆了，单个io时间仅仅指的是io操作在磁盘内部处理的时间，而io响应时间还要包括io操作在io等待队列中所花费的等待时间。
计算io操作在等待队列里面消耗的时间有一个衍生于利托氏定理(little’s law)的排队模型m/m/1模型可以遵循，由于排队模型算法比较复杂，到现在还没有搞太明白(如果有谁对m/m/1模型比较精通的话欢迎给予指导)，这里就罗列一下最后的结果，还是那上面计算的iops数据来说：
8k io chunk size (135 iops, 7.2 ms)
135 => 240.0 ms
105 => 29.5 ms
75 => 15.7 ms
45 => 10.6 ms
64k io chunk size(116 iops, 8.6 ms)
135 => 没响应了……
105 => 88.6 ms
75 => 24.6 ms
45 => 14.6 ms
从上面的数据可以看出，随着系统实际iops越接近理论的最大值，io的响应时间会成非线性的增长，越是接近最大值，响应时间就变得越大，而且会比预期超出很多。一般来说在实际的应用中有一个70%的指导值，也就是说在io读写的队列中，当队列大小小于最大iops的70%的时候，io的响应时间增加会很小，相对来说让人比较能接受的，一旦超过70%，响应时间就会戏剧性的暴增，所以当一个系统的io压力超出最大可承受压力的70%的时候就是必须要考虑调整或升级了。
另外补充说一下这个70%的指导值也适用于cpu响应时间，这也是在实践中证明过的，一旦cpu超过70%，系统将会变得受不了的慢。很有意思的东西。
利用CAN总线实现煤矿安全监控传输系统的设计
苹果首个AR应用将会出现在iPhone8身上？还支持3D摄像？
苹果炮轰高通最终目的是想自己最基带芯片
CES2017：京津冀人民的神器！像防毒面具的防雾霾口罩
Modbus TCP通讯概述
IO系统衡量性能的几个指标
扬尘噪声在线监测系统解决方案
我国物联网成绩与挑战并存
浪潮存储深入研究数据需求，以不断提升数据价值
三星确认投资智能设备 可穿戴市场竞争加剧
“场景化造车”再出新款，北汽新能源加速产品攻势
小米11成功解决曲面屏误触问题
从颜控到技术宅 格兰仕普罗旺斯空调顺利俘获消费者
一种新型通信用整流器
AMD Ryzen评测,相比Intel八代酷睿,AMD略胜一筹
海尔云梦洗衣机闪亮登场，打造全球一流品牌
一个非常简单的家庭电话铃声发生器电路
DLT Support in CANape
声控开关带强启线的接线步骤
2010卡塔尔国际建筑、建材博览会/卡塔尔多哈建筑建材展/新