本文核心内容是,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理应为一个不变的物理执行时间,却发生了变化,这到底为什么?
之前有一个错误观点,认为%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)
上面解释%util就已经说到了,因为svctm是被计算出来的。而这个算法对于非单块机械盘(RAID,SSD)并不适用。
这一点在sysstat最新文档中已经注明。可以另外参考:http://www.xaprb.com/blog/2010/09/06/beware-of-svctm-in-linuxs-iostat/
正确解读iostat命令的方法
这里给大家提供一个得到真正svctm的办法。
我们可以通过fio等压测工具,通过设置为同步IO,仅设置一个线程,io_depth也设置为1,压测出来的就是真正的service time(svctm),如果结果1
我们继续看算出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%时间
那么现在,如果我们不写工具,怎么根据现有的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人的年度之约!
专家阵容:或行业资深派、或著书力作派、或传统转型派、或一线实战派,总有一款是你喜欢!
绝对干货:聚焦架构、敏捷、运维三大主线,共讨传统企业在技术转型过程中的实践与困境、互联网企业在前沿技术方面的应用与心得、技术服务型企业在新老技术之间如何切换与落地,拒绝无营养的广告,绝对干货,精彩不容错过!
连接联动:汇聚社群数百顶级专家人脉,携数万社群成员声势,联合数十家媒体单位,共同打造一场连接敏捷与运维圈子的年度之约!
门票:免费!(限额)
VIP票:199元(限3月20日前)
如果字段的最大可能长度超过255字节,那么长度值可能…
只能说作者太用心了,优秀
感谢详解
一般干个7-8年(即30岁左右),能做到年入40w-50w;有…
230721