目录

一、IOPS

二、IO Response Time

三、Throughput

四、一些概念

五、性能参考（VMware场景、FusionSphere场景）

---

---

一、IOPS

即每秒钟处理的IO请求数量。IOPS是随机访问类型业务（OLTP类）很重要的一个参考指标。

• 一块物理硬盘能提供多少IOPS？

从磁盘上进行数据读取时，比较重要的几个时间是：寻址时间（找到数据块的起始位置），旋转时间（等待磁盘旋转到数据块的起始位置），传输时间（读取数据的时间和返回的时间）。其中寻址时间是固定的（磁头定位到数据的存储的扇区即可），旋转时间受磁盘转速的影响，传输时间受数据量大小的影响和接口类型的影响（不用硬盘接口速度不同），但是在随机访问类业务中，他的时间也很少。因此，在硬盘接口相同的情况下，IOPS主要受限于寻址时间和传输时间。以一个15K的硬盘为例，寻址时间固定为4ms，传输时间为60s/15000*1/2=2ms，忽略传输时间。1000ms/6ms=167个IOPS。

• OS的一次IO请求对应物理硬盘一个IO吗？

在没有文件系统、没有VM（卷管理）、没有RAID、没有存储设备的情况下，这个答案还是成立的。但是当这么多中间层加进去以后，这个答案就不是这样了。物理硬盘提供的IO是有限的，也是整个IO系统存在瓶颈的最大根源。所以，如果一块硬盘不能提供，那么多块在一起并行处理，这不就行了吗？确实是这样的。可以看到，越是高端的存储设备的cache越大，硬盘越多，一方面通过cache异步处理IO，另一方面通过盘数增加，尽可能把一个OS的IO分布到不同硬盘上，从而提高性能。文件系统则是在cache上会影响，而VM则可能是一个IO分布到多个不同设备上（Striping）。

所以，一个OS的IO在经过多个中间层以后，发生在物理磁盘上的IO是不确定的。可能是一对一个，也可能一个对应多个。

• IOPS能算出来吗？

对单块磁盘的IOPS的计算没有没问题，但是当系统后面接的是一个存储系统时、考虑不同读写比例，IOPS则很难计算，而需要根据实际情况进行测试。主要的因素有：  

• • 存储系统本身有自己的缓存。缓存大小直接影响IOPS，理论上说，缓存越大能cache的东西越多，在cache命中率保持的情况下，IOPS会越高。
  • RAID级别。不同的RAID级别影响了物理IO的效率。
  • 读写混合比例。对读操作，一般只要cache能足够大，可以大大减少物理IO，而都在cache中进行；对写操作，不论cache有多大，最终的写还是会落到磁盘上。因此，100%写的IOPS要越狱小于100%的读的IOPS。同时，100%写的IOPS大致等同于存储设备能提供的物理的IOPS。
  • 一次IO请求数据量的多少。一次读写1KB和一次读写1MB，显而易见，结果是完全不同的。

当时上面N多因素混合在一起以后，IOPS的值就变得扑朔迷离了。所以，一般需要通过实际应用的测试才能获得。 

二、IO Response Time

即IO的响应时间。IO响应时间是从操作系统内核发出一个IO请求到接收到IO响应的时间。因此，IO Response time除了包括磁盘获取数据的时间，还包括了操作系统以及在存储系统内部IO等待的时间。一般看，随IOPS增加，因为IO出现等待，IO响应时间也会随之增加。对一个OLTP系统，10ms以内的响应时间，是比较合理的。下面是一些IO性能示例：

• 一个8K的IO会比一个64K的IO速度快，因为数据读取的少些。
• 一个64K的IO会比8个8K的IO速度快，因为前者只请求了一个IO而后者是8个IO。
• 串行IO会比随机IO快，因为串行IO相对随机IO说，即便没有Cache，串行IO在磁盘处理上也会少些操作。

需要注意，IOPS与IO ResponseTime有着密切的联系。一般情况下，IOPS增加，说明IO请求多了，IO Response Time会相应增加。但是会出现IOPS一直增加，但是IO Response Time变得非常慢，超过20ms甚至几十ms，这时候的IOPS虽然还在提高，但是意义已经不大，因为整个IO系统的服务时间已经不可取。

三、Throughput

为吞吐量。这个指标衡量标识了最大的数据传输量。如上说明，这个值在顺序访问或者大数据量访问的情况下会比较重要。尤其在大数据量写的时候。

吞吐量不像IOPS影响因素很多，吞吐量一般受限于一些比较固定的因素，如：网络带宽、IO传输接口的带宽、硬盘接口带宽等。一般他的值就等于上面几个地方中某一个的瓶颈。

  

四、一些概念

 IO Chunk Size

即单个IO操作请求数据的大小。一次IO操作是指从发出IO请求到返回数据的过程。IO Chunk Size与应用或业务逻辑有着很密切的关系。比如像Oracle一类数据库，由于其block size一般为8K，读取、写入时都此为单位，因此，8K为这个系统主要的IOChunk Size。IO Chunk Size

小，考验的是IO系统的IOPS能力；IO Chunk Size大，考验的时候IO系统的IO吞吐量。

 

Queue Deep

熟悉数据库的人都知道，SQL是可以批量提交的，这样可以大大提高操作效率。IO请求也是一样，IO请求可以积累一定数据，然后一次提交到存储系统，这样一些相邻的数据块操作可以进行合并，减少物理IO数。而且Queue Deep如其名，就是设置一起提交的IO请求数量的。一般Queue Deep在IO驱动层面上进行配置。

Queue Deep与IOPS有着密切关系。Queue Deep主要考虑批量提交IO请求，自然只有IOPS是瓶颈的时候才会有意义，如果IO都是大IO，磁盘已经成瓶颈，Queue Deep意义也就不大了。一般来说，IOPS的峰值会随着QueueDeep的增加而增加(不会非常显著)，Queue Deep一般小于256。

 

随机访问（随机IO）、顺序访问（顺序IO）

随机访问的特点是每次IO请求的数据在磁盘上的位置跨度很大（如：分布在不同的扇区），因此N个非常小的IO请求（如：1K），必须以N次IO请求才能获取到相应的数据。

顺序访问的特点跟随机访问相反，它请求的数据在磁盘的位置是连续的。当系统发起N个非常小的IO请求（如：1K）时，因为一次IO是有代价的，系统会取完整的一块数据（如4K、8K），所以当第一次IO完成时，后续IO请求的数据可能已经有了。这样可以减少IO请求的次数。这也就是所谓的预取。

随机访问和顺序访问同样是有应用决定的。如数据库、小文件的存储的业务，大多是随机IO。而视频类业务、大文件存取，则大多为顺序IO。

  

选取合理的观察指标：

以上各指标中，不用的应用场景需要观察不同的指标，因为应用场景不同，有些指标甚至是没有意义的。

随机访问和IOPS: 在随机访问场景下，IOPS往往会到达瓶颈，而这个时候去观察Throughput，则往往远低于理论值。

顺序访问和Throughput：在顺序访问的场景下，Throughput往往会达到瓶颈（磁盘限制或者带宽），而这时候去观察IOPS，往往很小

计算磁盘理论最大IOPS的方法如下：

理论上可以计算出磁盘的平均最大IOPS，即IOPS = 1000 ms/ (Tseek + Troatation)，忽略数据传输时间。
假设磁盘平均物理寻道时间为3ms, 磁盘转速为7200,10K,15K rpm，则磁盘IOPS理论最大值分别为， 
IOPS = 1000 / (3 + 60000/7200/2) = 140 
IOPS = 1000 / (3 + 60000/10000/2) = 167 
IOPS = 1000 / (3 + 60000/15000/2) = 200

五、性能参考（VMware场景、FusionSphere场景）

VMware场景：

FusionSphere场景：