iostat如何對linux硬盤IO性能進行檢測,針對這個問題,這篇文章詳細介紹了相對應(yīng)的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
近期公司安裝了幾臺DELL PE2650和2850的服務(wù)器,統(tǒng)一安裝的是RHLE5.132位系統(tǒng),而服務(wù)器的SCSI硬盤都統(tǒng)一做了raid1。公司老總要求對硬盤IO作統(tǒng)一檢測報告,在Linux下找了許多工具,發(fā)現(xiàn)最實用的還是iostat,這個需要先安裝sysstat ,即yum -y install sysstat;公司內(nèi)部的yum服務(wù)器搭建這個不是本文的重點,這里不作詳細敘述。
# iostat -x 1 10
Linux 2.6.18-92.el5xen 03/01/2010
avg-cpu: %user %nice %system %iowait %steal %idle
1.10 0.00 4.82 39.54 0.07 54.46
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.16
rrqm/s:每秒進行 merge 的讀操作數(shù)目。即 delta(rmerge)/s
wrqm/s: 每秒進行 merge 的寫操作數(shù)目。即 delta(wmerge)/s
r/s: 每秒完成的讀 I/O 設(shè)備次數(shù)。即 delta(rio)/s
w/s: 每秒完成的寫 I/O 設(shè)備次數(shù)。即 delta(wio)/s
rsec/s:每秒讀扇區(qū)數(shù)。即 delta(rsect)/s
wsec/s: 每秒寫扇區(qū)數(shù)。即 delta(wsect)/s
rkB/s: 每秒讀K字節(jié)數(shù)。是 rsect/s 的一半,因為每扇區(qū)大小為512字節(jié)。(需要計算)
wkB/s:每秒寫K字節(jié)數(shù)。是 wsect/s 的一半。(需要計算)
avgrq-sz:平均每次設(shè)備I/O操作的數(shù)據(jù)大小 (扇區(qū))。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:平均I/O隊列長度。即 delta(aveq)/s/1000 (因為aveq的單位為毫秒)。
await:平均每次設(shè)備I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm:平均每次設(shè)備I/O操作的服務(wù)時間 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的時間用于 I/O 操作,或者說一秒中有多少時間 I/O 隊列是非空的。即 delta(use)/s/1000 (因為use的單位為毫秒)
如果%util接近100%,說明產(chǎn)生的I/O請求太多,I/O系統(tǒng)已經(jīng)滿負荷,該磁盤
可能存在瓶頸;idle小于70% IO壓力就較大了,一般讀取速度有較多的wait。
同時可以結(jié)合vmstat 查看查看b參數(shù)(等待資源的進程數(shù))和wa參數(shù)(IO等待所占用的CPU時間的百分比,高過30%時IO壓力高)
另外還可以參考
一般:
svctm < await(因為同時等待的請求的等待時間被重復(fù)計算了),
svctm的大小一般和磁盤性能有關(guān):CPU/內(nèi)存的負荷也會對其有影響,請求過多也會間接導(dǎo)致 svctm 的增加。
await:await的大小一般取決于服務(wù)時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發(fā)出模式。
如果svctm 比較接近await,說明I/O 幾乎沒有等待時間;
如果await 遠大于svctm,說明I/O隊列太長,應(yīng)用得到的響應(yīng)時間變慢
如果響應(yīng)時間超過了用戶可以容許的范圍,這時可以考慮更換更快的磁盤,調(diào)整內(nèi)核elevator算法,優(yōu)化應(yīng)用,或者升級 CPU。
隊列長度(avgqu-sz)也可作為衡量系統(tǒng) I/O 負荷的指標(biāo),但由于 avgqu-sz 是按照單位時間的平均值,所以不能反映瞬間的 I/O 洪水。
別人一個不錯的例子(I/O 系統(tǒng)vs超市排隊)
舉一個例子,我們在超市排隊 checkout 時,怎么決定該去哪個交款臺呢? 首當(dāng)是看排的隊人數(shù),5個人總比20人要快吧?除了數(shù)人頭,我們也常??纯辞懊嫒速徺I的東西多少,如果前面有個采購了一星期食品的大媽,那么可以考慮換個隊排了。還有就是收銀員的速度了,如果碰上了連錢都點不清楚的新手,那就有的等了。另外,時機也很重要,可能 5分鐘前還人滿為患的收款臺,現(xiàn)在已是人去樓空,這時候交款可是很爽啊,當(dāng)然,前提是那過去的 5 分鐘里所做的事情比排隊要有意義(不過我還沒發(fā)現(xiàn)什么事情比排隊還無聊的)。
I/O 系統(tǒng)也和超市排隊有很多類似之處:
r/s+w/s 類似于交款人的總數(shù)
平均隊列長度(avgqu-sz)類似于單位時間里平均排隊人的個數(shù)
平均服務(wù)時間(svctm)類似于收銀員的收款速度
平均等待時間(await)類似于平均每人的等待時間
平均I/O數(shù)據(jù)(avgrq-sz)類似于平均每人所買的東西多少
I/O 操作率 (%util)類似于收款臺前有人排隊的時間比例。
我們可以根據(jù)這些數(shù)據(jù)分析出 I/O 請求的模式,以及 I/O 的速度和響應(yīng)時間。
下面是別人寫的這個參數(shù)輸出的分析
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
上面的 iostat 輸出表明秒有 28.57 次設(shè)備 I/O 操作: 總IO(io)/s = r/s(讀) +w/s(寫) = 1.02+27.55 = 28.57 (次/秒) 其中寫操作占了主體 (w:r = 27:1)。
平均每次設(shè)備 I/O 操作只需要 5ms 就可以完成,但每個I/O 請求卻需要等上 78ms,為什么? 因為發(fā)出的 I/O 請求太多 (每秒鐘約29 個),假設(shè)這些請求是同時發(fā)出的,那么平均等待時間可以這樣計算:
平均等待時間 = 單個I/O 服務(wù)時間 * ( 1 + 2 + ... + 請求總數(shù)-1) / 請求總數(shù)
應(yīng)用到上面的例子: 平均等待時間 = 5ms * (1+2+...+28)/29 = 70ms,和 iostat 給出的78ms 的平均等待時間很接近。這反過來表明 I/O 是同時發(fā)起的。
每秒發(fā)出的 I/O 請求很多 (約29 個),平均隊列卻不長 (只有2 個左右),這表明這 29 個請求的到來并不均勻,大部分時間 I/O 是空閑的。
一秒中有 14.29% 的時間 I/O 隊列中是有請求的,也就是說,85.71% 的時間里 I/O 系統(tǒng)無事可做,所有 29 個I/O 請求都在142毫秒之內(nèi)處理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s=78.21 * delta(io)/s = 78.21*28.57 =2232.8,表明每秒內(nèi)的I/O請求總共需要等待2232.8ms。所以平均隊列長度應(yīng)為 2232.8ms/1000ms = 2.23,而iostat 給出的平均隊列長度 (avgqu-sz) 卻為22.35,為什么?因為iostat 中有bug,avgqu-sz值應(yīng)為2.23,而不是22.35。
※附帶說明下,我用iostat對服務(wù)器檢測時,一般用iostat -d命令;而返回的結(jié)果,我關(guān)注的一般是tps、blk_read/s、blk_wrth/s這三項,我一般是拿三臺不同型號的服務(wù)器在相同環(huán)境下作對比測試,這樣性能上的差異,一下子就出來了。
關(guān)于iostat如何對linux硬盤IO性能進行檢測問題的解答就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道了解更多相關(guān)知識。
本文名稱:iostat如何對linux硬盤IO性能進行檢測-創(chuàng)新互聯(lián)
網(wǎng)頁鏈接:http://chinadenli.net/article4/diceoe.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站內(nèi)鏈、用戶體驗、靜態(tài)網(wǎng)站、品牌網(wǎng)站建設(shè)、網(wǎng)站制作、網(wǎng)站設(shè)計公司
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容