Linux磁碟下檢視I/O磁碟的效能

iostat檢視Linux硬碟IO效能

rrqm/s:每秒進行merge的讀運算元目。即delta(rmerge)/s
wrqm/s:每秒進行merge的寫運算元目。即delta(wmerge)/s
r/s:每秒完成的讀I/O裝置次數。即delta(rio)/s
w/s:每秒完成的寫I/O裝置次數。即delta(wio)/s
rsec/s:每秒讀磁區數。即delta(rsect)/s
wsec/s:每秒寫磁區數。即delta(wsect)/s
rkB/s:每秒讀K位元組數。是rsect/s的一半，因為每磁區大小為512位元組。(需要計算)
wkB/s:每秒寫K位元組數。是wsect/s的一半。(需要計算)
avgrq-sz:平均每次裝置I/O操作的資料大小(磁區)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:平均I/O佇列長度。即delta(aveq)/s/1000(因為aveq的單位為毫秒)。
await:平均每次裝置I/O操作的等待時間(毫秒)。即delta(ruse+wuse)/delta(rio+wio)
svctm:平均每次裝置I/O操作的服務時間(毫秒)。即delta(use)/delta(rio+wio)
%util:一秒中有百分之多少的時間用於I/O操作，或者說一秒中有多少時間I/O佇列是非空的。即delta(use)/s/1000(因為use的單位為毫秒)

如果%util接近100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁碟
可能存在瓶頸。
idle小於70%IO壓力就較大了,一般讀取速度有較多的wait.
同時可以結合vmstat檢視檢視b引數()和wa引數()

另外還可以參考
svctm一般要小於await(因為同時等待的請求的等待時間被重複計算了)，svctm的大小一般和磁碟效能有關，CPU/記憶體的負荷也會對其有影響，請求過多也會間接導致svctm的增加。await的大小一般取決於服務時間(svctm)以及I/O佇列的長度和I/O請求的發出模式。如果svctm比較接近await，說明I/O幾乎沒有等待時間；如果await遠大於svctm，說明I/O佇列太長，應用得到的響應時間變慢，如果響應時間超過了使用者可以容許的範圍，這時可以考慮更換更快的磁碟，調整核心elevator演算法，優化應用，或者升級CPU。
佇列長度(avgqu-sz)也可作為衡量系統I/O負荷的指標，但由於avgqu-sz是按照單位時間的平均值，所以不能反映瞬間的I/O洪水。

別人一個不錯的例子.(I/O系統vs.超市排隊)

舉一個例子，我們在超市排隊checkout時，怎麼決定該去哪個交款台呢?首當是看排的隊人數，5個人總比20人要快吧?除了數人頭，我們也常常看看前面人購買的東西多少，如果前面有個採購了一星期食品的大媽，那麼可以考慮換個隊排了。還有就是收銀員的速度了，如果碰上了連錢都點不清楚的新手，那就有的等了。另外，時機也很重要，可能5分鐘前還人滿為患的收款台，現在已是人去樓空，這時候交款可是很爽啊，當然，前提是那過去的5分鐘裡所做的事情比排隊要有意義(不過我還沒發現什麼事情比排隊還無聊的)。

I/O系統也和超市排隊有很多類似之處:

r/s+w/s類似於交款人的總數
平均佇列長度(avgqu-sz)類似於單位時間裡平均排隊人的個數
平均服務時間(svctm)類似於收銀員的收款速度
平均等待時間(await)類似於平均每人的等待時間
平均I/O資料(avgrq-sz)類似於平均每人所買的東西多少
I/O操作率(%util)類似於收款台前有人排隊的時間比例。

我們可以根據這些資料分析出I/O請求的模式，以及I/O的速度和響應時間。

下面是別人寫的這個引數輸出的分析

#iostat-x1
avg-cpu:%user%nice%sys%idle
16.240.004.3179.44
Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util
/dev/cciss/c0d0
0.0044.901.0227.558.16579.594.08289.8020.5722.3578.215.0014.29
/dev/cciss/c0d0p1
0.0044.901.0227.558.16579.594.08289.8020.5722.3578.215.0014.29
/dev/cciss/c0d0p2
0.000.000.000.000.000.000.000.000.000.000.000.000.00

上面的iostat輸出表明秒有28.57次裝置I/O操作:總IO(io)/s=r/s(讀)+w/s(寫)=1.02+27.55=28.57(次/秒)其中寫操作佔了主體(w:r=27:1)。

平均每次裝置I/O操作只需要5ms就可以完成，但每個I/O請求卻需要等上78ms，為什麼?因為發出的I/O請求太多(每秒鐘約29個)，假設這些請求是同時發出的，那麼平均等待時間可以這樣計算:

平均等待時間=單個I/O服務時間*(1+2+…+請求總數-1)/請求總數

應用到上面的例子:平均等待時間=5ms*(1+2+…+28)/29=70ms，和iostat給出的78ms的平均等待時間很接近。這反過來表明I/O是同時發起的。

每秒發出的I/O請求很多(約29個)，平均佇列卻不長(只有2個左右)，這表明這29個請求的到來並不均勻，大部分時間I/O是空閒的。

一秒中有14.29%的時間I/O佇列中是有請求的，也就是說，85.71%的時間裡I/O系統無事可做，所有29個I/O請求都在142毫秒之內處理掉了。

delta(ruse+wuse)/delta(io)=await=78.21=>delta(ruse+wuse)/s=78.21*delta(io)/s=78.21*28.57=2232.8，表明每秒內的I/O請求總共需要等待2232.8ms。所以平均佇列長度應為2232.8ms/1000ms=2.23，而iostat給出的平均佇列長度(avgqu-sz)卻為22.35，為什麼?!因為iostat中有bug，avgqu-sz值應為2.23，而不是22.35。

本文永久更新連結地址：http://www.linuxidc.com/Linux/2017-03/141314.htm