说说IO(三)- IO性能的重要指标
说说IO(三)- IO性能的重要指标
abcijkxyz 发表于2年前
说说IO(三)- IO性能的重要指标
  • 发表于 2年前
  • 阅读 0
  • 收藏 0
  • 点赞 0
  • 评论 0

新睿云服务器60天免费使用,快来体验!>>>   

最重要的三个指标

 

IOPS

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 Response Time有着密切的联系。一般情况下,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为这个系统主要的IO Chunk 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的峰值会随着Queue Deep的增加而增加(不会非常显著),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,往往很小。

  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
粉丝 59
博文 6195
码字总数 1876
×
abcijkxyz
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: