在研究磁盘性能之前我们必须先了解磁盘的结构,以及工作原理。不过在这里就不再重复说明了,关系硬盘结构和工作原理的信息可以参考维基百科上面的相关词条——Hard disk drive(英文)和硬盘驱动器(中文)。
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。
现在我们就可以得出这样的计算单次IO时间的公式:
于是我们可以这样计算出IOPS
对于给定不同的IO大小我们可以得出下面的一系列的数据
从上面的数据可以看出,当单次IO越小的时候,单次IO所耗费的时间也越少,相应的IOPS也就越大。
上面我们的数据都是在一个比较理想的假设下得出来的,这里的理想的情况就是磁盘要花费平均大小的寻址时间和平均的旋转延时,这个假设其实是比较符合我们实际情况中的随机读写,在随机读写中,每次IO操作的寻址时间和旋转延时都不能忽略不计,有了这两个时间的存在也就限制了IOPS的大小。现在我们考虑一种相对极端的顺序读写操作,比如说在读取一个很大的存储连续分布在磁盘的的文件,因为文件的存储的分布是连续的,磁头在完成一个读IO操作之后,不需要从新的寻址,也不需要旋转延时,在这种情况下我们能到一个很大的IOPS值,如下
相比第一组数据来说差距是非常的大的,因此当我们要用IOPS来衡量一个IO系统的系能的时候我们一定要说清楚是在什么情况的IOPS,也就是要说明读写的方式以及单次IO的大小,当然在实际当中,特别是在OLTP的系统的,随机的小IO的读写是最有说服力的。
现在我们要说的传输速度(另一个常见的说法是吞吐率)不是磁盘上所表明的最大传输速度或者说理想传输速度,而是磁盘在实际使用的时候从磁盘系统总线上流过的数据量。有了IOPS数据之后我们是很容易就能计算出对应的传输速度来的
还是那上面的第一组IOPS的数据我们可以得出相应的传输速度如下
可以看出实际上的传输速度是很小的,对总线的利用率也是非常的小。
这里一定要明确一个概念,那就是尽管上面我们使用IOPS来计算传输速度,但是实际上传输速度和IOPS是没有直接关系,在没有缓存的情况下它们共同的决定因素都是对磁盘系统的访问方式以及单个IO的大小。对磁盘进行随机访问时候我们可以利用IOPS来衡量一个磁盘系统的性能,此时的传输速度不会太大;但是当对磁盘进行连续访问时,此时的IOPS已经没有了参考的价值,这个时候限制实际传输速度却是磁盘的最大传输速度。因此在实际的应用当中,只会用IOPS来衡量小IO的随机读写的性能,而当要衡量大IO连续读写的性能的时候就要采用传输速度而不能是IOPS了。
最后来关注一下能直接描述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数据来说:
从上面的数据可以看出,随着系统实际IOPS越接近理论的最大值,IO的响应时间会成非线性的增长,越是接近最大值,响应时间就变得越大,而且会比预期超出很多。一般来说在实际的应用中有一个70%的指导值,也就是说在IO读写的队列中,当队列大小小于最大IOPS的70%的时候,IO的响应时间增加会很小,相对来说让人比较能接受的,一旦超过70%,响应时间就会戏剧性的暴增,所以当一个系统的IO压力超出最大可承受压力的70%的时候就是必须要考虑调整或升级了。
另外补充说一下这个70%的指导值也适用于CPU响应时间,这也是在实践中证明过的,一旦CPU超过70%,系统将会变得受不了的慢。很有意思的东西。
在当下的各种存储产品中,按照速度从快到慢应该就是内存>闪存>磁盘>磁带了,然而速度越快也就意味着价格越高,闪存虽然说是发展势头很好,但目前来说却还是因为价格问题无法普及,因此现在还是一个磁盘作霸王的时代。与CPU和内存速度相比,磁盘的速度无疑是计算机系统中最大的瓶颈了,所以在必须使用磁盘而又想提高性能的情况下,人们想出了在磁盘中嵌入一块高速的内存用来保存经常访问的数据从而提高读写效率的方法来折中的解决,这块嵌入的内存就被称为高速缓存。
说到缓存,这东西应用现在已经是无处不在,从处于上层的应用,到操作系统层,再到磁盘控制器,还有CPU内部,单个磁盘的内部也都存在缓存,所有这些缓存存在的目的都是相同的,就是提高系统执行的效率。当然在这里我们只关心跟IO性能相关的缓存,与IO性能直接相关的几个缓存分别是文件系统缓存(File System Cache)、磁盘控制器缓存(Disk Controller Cache)和磁盘缓存(Disk Cache,也称为Disk Buffer),不过当在计算一个磁盘系统性能的时候文件系统缓存也是不会考虑在内的,因此我们重点考察的就是磁盘控制器缓存和磁盘缓存。
不管是控制器缓存还是磁盘缓存,他们所起的作用主要是分为三部分:缓存数据、预读(Read-ahead)和回写(Write-back)。
缓存的命中率跟缓存的大小有很大的关系,理论上是缓存越大的话,所能缓存的数据也就越多,这样命中率也自然越高,当然缓存不可能太大,毕竟成本在那儿呢。如果一个容量很大的存储系统配备了一个很小的读缓存的话,这时候问题会比较大的,因为小缓存缓存的数据量非常小,相比整个存储系统来说比例非常低,这样随机读取(数据库系统的大多数情况)的时候命中率也自然就很低,这样的缓存不但不能提高效率(因为绝大部分读IO都还要读取磁盘),反而会因为每次去匹配缓存而浪费时间。
执行读IO操作是读取数据存在于缓存中的数量与全部要读取数据的比值称为缓存命中率(Read Cache Hit Radio),假设一个存储系统在不使用缓存的情况下随机小IO读取能达到150IOPS,而它的缓存能提供10%的缓存命中率的话,那么实际上它的IOPS可以达到150/(1-10%)=166。
读缓存虽然对效率提高是很明显的,但是它所带来的问题也比较严重,因为缓存和普通内存一样,掉点以后数据会全部丢失,当操作系统发出的写IO命令写入到缓存中后即被认为是写入成功,而实际上数据是没有被真正写入磁盘的,此时如果掉电,缓存中的数据就会永远的丢失了,这个对应用来说是灾难性的,目前解决这个问题最好的方法就是给缓存配备电池了,保证存储掉电之后缓存数据能如数保存下来。
和读一样,写缓存也存在一个写缓存命中率(Write Cache Hit Radio),不过和读缓存命中情况不一样的是,尽管缓存命中,也不能将实际的IO操作免掉,只是被合并了而已。
控制器缓存和磁盘缓存除了上面的作用之外还承当着其他的作用,比如磁盘缓存有保存IO命令队列的功能,单个的磁盘一次只能处理一个IO命令,但却能接收多个IO命令,这些进入到磁盘而未被处理的命令就保存在缓存中的IO队列中。
在任何时候IO响应时间值得都是单个IO的响应时间,因此,不管磁盘是否组成了磁盘阵列,它的IO响应时间应该都是一样的。从前面的计算中我们可以看到,如果IO响应时间在10ms左右的话是很正常的,但是当IO响应时间比这个值超出太多的时候,你就要开始注意了,很可能就意味着此时你的磁盘系统已经成为了一个瓶颈。
综合上面两个部分的讨论我们来估算一下阵列下的磁盘总体IOPS,在这里我们先假设组成阵列的单个磁盘的随机读写的IOPS为140,读写缓存命中率都为10%,组成阵列的磁盘个数为4。
因为不管是那种阵列,磁盘的读取性能都是所有磁盘之和,所以可以得出下面的读取IOPS:
而写入性能就完全不一样了,根据上面的讨论我们可以得出下面结论:
由此我们也可以计算出写入IOPS估算公式:
实际上从通过上面的计算方法我们还可以估算当给定一个要求的IOPS的情况下,估计下使用各个阵列级别所需要的磁盘的数量。当然我们上面的计算方法只是一个估算,我们忽略很多其他的因素,得出的只是一个大概的数值,不过在实际的应用还是有一定的参考作用的。
本篇最后附送一个计算磁盘系统IOPS的网站――wmarow’s disk & disk array calculator,这个网站提供的计算公式还考虑了诸如阵列条带大小以及主机方面的因素,很有参考价值,至于怎么选择合适的条带大小,请参考【延伸阅读】部分。
实际上估算除了随机读写的IOPS也就知道了随机读写的吞吐率。对于顺序读写的呢,还是跟前一篇所讲的一样,主要受限于磁盘的限制,不能再拿IOPS来衡量了。
dd其实是工作于比较低层的一个数据拷贝和转换的*nix平台的工具,但是因为dd命令支持*nix平台的一些特殊设备,因此我们可以利用dd命令的这个特性来简单的测试磁盘的性能。
先说一下两个相关的特殊设备
于是就有了下面的用法:
这个命令时往磁盘的文件/tmp/foo中写入一个4G大小的文件,当然文件的内容全部是空字符了,同时用/usr/bin/time来对命令的执行进行计时,命令中的bs指的是写入文件时的块大小,其实就相当于Oracle中的block大小了,count是写入的块数。采取这种方法来写入数据时只是测试的连续读磁盘的性能,而不是随机读的性能,不能采取这种方法检查一个机器的IOPS的,只能检查磁盘的吞吐率。
上面的命令是从/tmp/foo文件中读取数据,然后扔掉,这里bs用的是读取时块的大小。和上面写入的命令一样,这样测试的仅仅是最大的读取性能,而不是随机IO的性能。
在上面的命令中都用到了time命令对操作进行计时,这样才能正确的进行判断。要记住的一点是dd命令只能够提供一个大概的测试,通过这个简单的命令可以对磁盘系统的最大性能有一个大概的了解,要了解更详细的信息还要通过其他方法来查看。
在Linux中,我们执行一个iostat -x命令,我们能看到如下的输出
我们先列举一下各个性能指标的简单说明。
要理解这些性能指标我们先看下图
上图的左边是iostat显示的各个性能指标,每个性能指标都会显示在一条虚线之上,这表明这个性能指标是从虚线之上的那个读写阶段开始计量的,比如说图中的w/s从Linux IO scheduler开始穿过硬盘控制器(CCIS/3ware),这就表明w/s统计的是每秒钟从Linux IO scheduler通过硬盘控制器的写IO的数量。
结合上图对读IO操作的过程做一个说明,在从OS Buffer Cache传入到OS Kernel(Linux IO scheduler)的读IO操作的个数实际上是rrqm/s+r/s,直到读IO请求到达OS Kernel层之后,有每秒钟有rrqm/s个读IO操作被合并,最终转送给磁盘控制器的每秒钟读IO的个数为r/w;在进入到操作系统的设备层(/dev/sda)之后,计数器开始对IO操作进行计时,最终的计算结果表现是await,这个值就是我们要的IO响应时间了;svctm是在IO操作进入到磁盘控制器之后直到磁盘控制器返回结果所花费的时间,这是一个实际IO操作所花的时间,当await与svctm相差很大的时候,我们就要注意磁盘的IO性能了;而avgrq-sz是从OS Kernel往下传递请求时单个IO的大小,avgqu-sz则是在OS Kernel中IO请求队列的平均大小。
现在我们可以将iostat输出结果和我们前面讨论的指标挂钩了。
前面说过IO在执行过程中会被合并以提高效率,下面就结合dd命令和iostat命令看一下。
我们先执行dd命令,设置bs参数值为1k,完整命令如下
同时打开另外一个终端执行iostat命令,这里只查看变化那个磁盘的更改,每秒刷新一次数据,完整命令如下
然后我们可以得到下面的结果
看结果中第一组数据中的avgrq-sz,为103.89个扇区,磁盘的每个扇区为512字节,因此平均IO大小为103.89*512/1024=52k字节,远远大于我们dd命令时给定的参数1k字节,也就是说IO在中间被合并了。看巨大的wrqm/s也能得出同样的结论。