与时俱进:iostat核心变化解读

代海鹏 2016-03-15 09:40:09
近些年,存储技术飞速发展,有些OS命令的输出结果如果用老的思路去分析,就很容易进入误区。本文不是一篇iostat的科普文,我将深入解析的是大家使用iostat时常遇的问题。iostat 是sysstat工具包中重要的一员,而sysstat工具包在各类Linux操作系统中都适用,所以本文具有一定的普适性。

本文核心内容是,iostat实时看到的util%和svctm值只适用于传统硬盘时代,现在已不可取,需重新解读。


目录

  • 通过SSD盘压测,解读util%的差异

  • Iostat命令核心条目解读

  • 核心问题阐述及解释

  • 正确解读iostat命令的方法


通过SSD盘压测,解读util%的差异

 

压测采用同一块SSD盘,SSD盘分配的盘符为sdb1,请注意两次压测的不同之处。


第一次压测结果(A):



第一次压测命令:



第二次压测结果(B):



第二次压测命令:



从这里我们可以明显看出,%util值和svctm值是存在很大问题的,都是100%,为什么IOPS一个只达到1416,而另外一个却可以达到9342。


通过下面一步步的解释,希望可以帮助大家解除疑惑。


Iostat命令核心条目解读

 

在解释之前,首先简单科普一下相关条目的意思。



1、r/s + w/s:就是当前的IOPS(每秒IO数量)


2、await:请求队列中等待时间+svctm(服务时间) ,单位是毫秒,按照每次IO平均。


3、svctm:


IO平均服务时间指物理设备处理时间,不包含主机层面的排队等待时间,所以理论上应为不变值。


服务时间包括磁头寻道时间(目前平均为3毫秒)+旋转延迟时间(磁盘转速相关)+数据传输时间(简单计算时可忽略不计)


旋转延迟时间一般以旋转一周时间的1/2表示。

  • 7200转的为 60/7200/2 =0.00416666..秒=4.17毫秒

  • 15000转为 60/15000/2=0.002秒=2毫秒


4、%util:设备使用率,越接近100,表示压力越大。


核心问题阐述及解释

 

通过之前两次压测结果,我们初步得到以下两点:


 

1、%util达到100%并不能表示压力完全繁忙。

2、svctm理应为一个不变的物理执行时间,却发生了变化,这到底为什么?

 

1
 
为什么%util值不再代表正确繁忙度?
 

之前有一个错误观点,认为%util达到100%磁盘就已经完全繁忙了,其实并不是。


机械硬盘时代(比如15000转的盘),在物理层面是串行的,一个时间只能干一个活。虽然有各种级别的concurrency,但并不是真正的并行。


SSD,RAID 则不同。他们可以真正在物理层面上并行执行多个IO。可以同时物理执行多个IO。


%util的计算 有一个简单的算法:

concurrency = (r/s + w/s) * (svctm / 1000)

%util = concurrency * 100%


然而这个concurrency  是个伪命题,因为svctm也是通过计算而来的,无论怎样压,算出来的concurrency都是1左右,那么自然util% 乘以出来就是100%


举例说明:


一个快递员的繁忙程度(uti%)是看这个快递员在一定时间内,真正用于工作的时间是多少。


统计时间为10分钟,如果10分钟内快递员一口水都没喝,都在跑来跑去地忙活。那么我们可以认定繁忙率是100%


这就是util%的计算方法。这种方法对于单块机械磁盘(串行IO)没有任何问题。


技术在进步,出现了SSD以及RAID后,我们就可以并行的执行IO。


在刚刚的例子中,这个快递员变成了漩涡鸣人,会分身术,它可以分出15个分身,一起出去送快递。


但原本的算法,只盯着漩涡鸣人本身,10分钟内跑来跑去,就认为他100%繁忙。


其实他真正的百分百繁忙时,应该是本身和15个分身,总计16个漩涡鸣人全部跑来跑去送快递。


在快递员会分身术后,util%算法便有了局限性。


看了这个例子,大家应该知道通过查看%util来确认压力大小已经非常不可取了。


而且在sysstat网站的最新文档中也已经注明: But for devices serving requests in parallel, such as RAID arrays and modern SSDs, this number does not reflect their performance limits.  (文档地址:http://sebastien.godard.pagesperso-orange.fr/man_iostat.html)


2
 
为什么svctm值会发生变化?
 

上面解释%util就已经说到了,因为svctm是被计算出来的。而这个算法对于非单块机械盘(RAID,SSD)并不适用。


这一点在sysstat最新文档中已经注明。可以另外参考:http://www.xaprb.com/blog/2010/09/06/beware-of-svctm-in-linuxs-iostat/


正确解读iostat命令的方法

 
 
1
 
我们怎样获得真正的serviice time(svctm)?
 

这里给大家提供一个得到真正svctm的办法。


我们可以通过fio等压测工具,通过设置为同步IO,仅设置一个线程,io_depth也设置为1,压测出来的就是真正的service time(svctm),如果结果1


2
 
我们怎样获得某磁盘或lun的io最大并行度,如何获得真正的util%使用率?
 

我们继续看算出util%的公式是什么:


concurrency = (r/s + w/s) * (svctm / 1000)
%util = concurrency * 100%


这个公式的前提是svctm是个不变的固定物理处理时间。但是我们可以从上面的两次压测结果看出其时间也是计算出来,随着iops增加,svctm相应减少。自然该公式无论如何算都是100%。 


我们首先带入第二次压测结果


concurrency = (9342 + 0) * (0.11 / 1000)

concurrency = 1.02762


第二次util%还是显示100%,这是根据公式推出的答案,但是此结果是错误的。


我想到一个办法,我们将svctm带入成一个常量,即我们之前第一次压测出来的真正物理处理时间。结果如下:


concurrency = (9342+0) * (0.61 / 1000) =5.63762

concurrency = 5.63762

util% = 563.762%


我们可以通过写小工具,调用iostat -x的结果,并且将实时svctm替换为事先压测好的真实svctm(实际物理处理时间),这样就可以算出真实的util%时间


3
 
算出真实的最大并行度有什么用?
 

那么现在,如果我们不写工具,怎么根据现有的iostat值,加上之前的压测成果,判断是否繁忙呢?


现在已知util% ,svctm 都不准确。我们这里应该参考avgqu-sz。


avgqu-sz:超过处理能力的请求数目,待处理的 I/O 请求,当请求持续超出磁盘处理能力,该值将增加。 


我们通过实际经验得到,当该值持续超过读写能力的1.5倍时,就表示磁盘十分繁忙。


网上的一些文章中会写到,如果该值超过2那么可以认定磁盘繁忙,其实这是一种过时的理论。


这里的2,也是基于单块机械硬盘的IO能力得出的经验结论。我们之前说过,单块机械硬盘为串行化IO,物理层面同时只能有一个IO在处理(即处理能力为1)。


那么这里的等待处理为2,是对应于磁盘处理能力为1。


那么当RAIDs 或者 SSD等并行方式,如我们压测的磁盘通过上面带入正确值的公式,我们可以实现并行度为5.63,根据之前理论,应该是超过5.63的两倍,如11.26,而不再是一个固定的值2。是否为2在当前情况已经无法判断是否繁忙。


我们这里通过压测得知,在ssd或raid情况下,等待基本不可能达到读写能力的两倍,1.5倍基本就代表非常繁忙, 而1倍的时候就需要注意了。


这里我们看第二个压测结果的qvgqu-sz值为9.21。


压测满时的等待处理io值为9.21,并行度为5.63。

9.21/5.63=1.63


从值看出,在压满的情况下,avgqu-sz为并行度的1.6倍左右。


我们可以得出结论:在事先有压测结果,知道并行度的情况下,我们可以通过查看avgqu-sz是否为并行度的1.5倍来判断该磁盘是否繁忙。


还有一个更简单主观的识别方法,即当svctm和await时间相差过大(await>>svctm)时,就可判断系统层面已经排队时间过高了,此时系统IO压力很大,要引起注意了。


但是该方法只适合经验派使用,因为它无法给出一个精准的值作为参考,也无法作为问题的发现依据写入文档。


如果你还有什么疑惑,可以将问题写在评论中,我们可以一起探讨分析。


作者介绍:代海鹏

  • 新炬网络资深数据库工程师。

  • 5年+Oracle维护经验,曾为中国人寿、中国移动、国家电网等大型企业提供数据库技术支持服务。

  • 擅长数据库性能优化、故障诊断。


 

全球敏捷运维峰会【杭州站】

 
 
 


2016 年4月16日,与你相约杭州,来一场敏捷与运维的美丽邂逅!DBA+社群联合三墩IT人开启全球敏捷运维峰会第一站:杭州站!峰会力邀来自互联网与传统企 业的资深专家,各路大咖齐聚,汇聚500+行业精英,聚焦架构、敏捷、运维三大主线,开启一场专属于IT人的年度之约!


专家阵容:或行业资深派、或著书力作派、或传统转型派、或一线实战派,总有一款是你喜欢!


绝对干货:聚焦架构、敏捷、运维三大主线,共讨传统企业在技术转型过程中的实践与困境、互联网企业在前沿技术方面的应用与心得、技术服务型企业在新老技术之间如何切换与落地,拒绝无营养的广告,绝对干货,精彩不容错过!


连接联动:汇聚社群数百顶级专家人脉,携数万社群成员声势,联合数十家媒体单位,共同打造一场连接敏捷与运维圈子的年度之约!


票价优惠

 
原价
 
 
门票:99元
VIP票:299元(含VIP坐席、午餐)
限时优惠
 
 

门票:免费!(限额)

VIP票:199元(限3月20日前)

 
报名方式:猛戳“Gdevops官网”,名额有限哦~
最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告