iostat的研究和分析

爲更好了解iostat的用法，正確的分析，系統IO瓶頸，找了些資料，作個小結：

 

先是英文的：

So in order to use the linux performance tools you must first calibrate the system performance tools to your systems "Steady Rate". This Steady Rate is when the math works. 1+1 must always = 2.

This is Queuing Theory from Little's Law (Google both).

The short and sweet is: Length = Arrival Rate * Wait

So a perfect example would be 'iostat -x 1 5' Take a sample and do the math.

Device: rrqm/s   wrqm/s   r/s    w/s       rsec/s   wsec/s   avgrq-sz  avgqu-sz await    svctm  %util
sda            0.00   184.00   15.00  126.00  240.00   2480.00     19.29       0.15         1.06     0.07   1.00

L=AWAIT
AR=r/s+w/s
W=SVCTM (NOTE THE DIFFERENCE!! SVCTM is in Milliseconds! So you must convert so all your units are the same!!!! THIS IS KEY!)

1.06 = (15+126)*.007

1.06= = .987

Variance = 6.9%

That's pretty close, but now change your observation window to see if you can get even more precise. 'iostat -x 2 5'

Device: rrqm/s   wrqm/s   r/s         w/s     rsec/s  wsec/s    avgrq-sz avgqu-sz await   svctm   %util
sda            0.00     1.50        0.00   608.50    0.00    4880.00         8.02     40.64         57.75    0.60   36.55

 

57.75 = (0+608.5) * .60

57.75 = 36.51 (Not even worth calculating the variance since it's just way off.)

This means that your systems Steady Rate is 1 second intervals. Not all tools are alike, so each must be calibrated before being used to measure.

 

 

技術指標的中文意思：

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參數(IO等待所佔用的CPU時間的百分比,高過30%時IO壓力高)
另外 await 的參數也要多和 svctm 來參考。差的太高就必定有 IO 的問題。
avgqu-sz 也是個作 IO 調優時須要注意的地方，這個就是直接每次操做的數據的大小，若是次數多，但數據拿的小的話，其實 IO 也會很小.若是數據拿的大，才IO 的數據會高。也能夠經過 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是講，讀定速度是這個來決定的。

 

 

 

另外還能夠參考
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 -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

上面的 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。