Linux系統出現了性能問題，一般我們可以通過top.iostat,vmstat等命令來查看初步定位問題。其中iostat可以給我們提供豐富的IO狀態數據。 www.jb51.net
iostat結果分析
[kefu@SZ-8 linux]$ iostat -x -k
Linux 2.6.18-128.el5_cyou_1.0 (SZ-8.30) 09/08/2011
avg-cpu: %user %nice %system %iowait %steal %idle
16.58 0.00 2.79 0.46 0.00 80.16
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.06 29.28 0.22 37.14 10.21 265.68 14.77 0.02 0.51 0.15 0.55
sda1 0.00 0.00 0.00 0.00 0.00 0.00 10.79 0.00 2.66 2.43 0.00
sda2 0.01 0.78 0.10 0.36 0.81 4.58 23.51 0.00 1.21 0.84 0.04
sda3 0.03 15.17 0.09 35.39 8.98 202.24 11.91 0.01 0.26 0.12 0.44
sda4 0.00 0.00 0.00 0.00 0.00 0.00 2.00 0.00 33.33 33.33 0.00
sda5 0.01 1.59 0.03 0.51 0.34 8.40 32.20 0.00 1.19 0.58 0.03
sda6 0.00 0.00 0.00 0.12 0.00 0.48 8.18 0.00 5.02 4.53 0.05
sda7 0.00 0.00 0.00 0.00 0.00 0.00 45.00 0.00 5.52 3.04 0.00
sda8 0.00 0.00 0.00 0.00 0.00 0.00 40.88 0.00 7.62 6.03 0.00
sda9 0.00 0.00 0.00 0.00 0.00 0.00 39.71 0.00 7.37 5.83 0.00
sda10 0.00 0.00 0.00 0.00 0.00 0.00 37.57 0.00 5.70 3.54 0.00
sda11 0.00 11.74 0.01 0.76 0.08 49.97 131.48 0.01 10.74 0.57 0.04
sdb 0.01 3.91 20.24 20.21 1262.95 1853.94 154.09 0.52 12.84 1.97 7.95
rrqm/s:每秒進行merge的讀操作數目。即delta(rmerge)/s
wrqm/s:每秒進行merge的寫操作數目。即delta(wmerge)/s
r/s:每秒完成的讀I/O設備次數。即delta(rio)/s
w/s:每秒完成的寫I/0設備次數。即delta(wio)/s
rsec/s:每秒讀扇區數。即delta(rsect)/s
wsec/s:每秒寫扇區數。即delta(wsect)/s
rKB/s:每秒讀K字節數。是rsec/s的一半，因為每扇區大小為512字節
wKB/s:每秒寫K字節數。是wsec/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(usr)/s/1000(因為use的單位為毫秒)
如果%util接近100%,說明產生的I/O請求太多,I/O系統已經滿負載,該磁盤可能存在瓶頸。
比較重要的參數
%util:一秒中有百分之多少的時間用於I/O操作，或者說一秒中有多少時間I/O隊列是非空的
svctm:平均每次設備I/O操作的服務時間
await:平均每次設備I/O操作的等待時間
avgqu-sz:平均I/O隊列長度
如果%util接近100%,表明I/O請求太多,I/O系統已經滿負荷，磁盤可能存在瓶頸,一般%util大於70%,I/O壓力就比較大，讀取速度有較多的wait。
同時可以結合vmstat查看查看b參數(等待資源的進程數)和wa參數(I/O等待所占用的CPU時間的百分比,高過30%時I/O壓力高)
await的大小一般取決於服務時間(svctm)以及I/O隊列的長度和I/O請求的發出模式。如果svctm比較接近await,說明I/O幾乎沒有等待時間;如果
await遠大於svctm,說明I/O隊列太長，應用得到的響應時間變慢。
形象的比喻
r/s+w/s類似於交款人的總數
平均隊列長度(avgqu-sz)類似於單位時間裡平均排隊的人數
平均服務時間(avctm)類似於收銀員的收款速度
平均等待時間(await)類似於平均每人的等待時間
平均I/O數據(avgrq-sz)類似於平均每人所買的東西
I/O操作率(%util)類似於收款台前有人排隊的時間比例
svctm一般要小於await(因為同時等待的請求的等待時間被重復計算了),svctm的大小一般和磁盤性能有關,CPU/內存的負荷也會對其有影響，請求過多也會
間接導致svctm的增加。await的大小一般取決於服務時間(svctm)以及I/O隊列的長度和I/O請求的發出模式。如果svctm比較接近await,說明I/O幾乎沒有
等待時間;如果await遠大於svctm,說明I/O隊列太長，應用得到的響應時間變慢,如果響應時間超過了用戶可以容許的范圍,這時可以考慮更換更快的磁盤,調
整內核elevator算法,優化應用,或者升級CPU
隊列長度(avcqu-sz)也可作為衡量系統I/O負荷的指標,但由於avcqu-sz是按照單位時間的平均值,所以不能反映瞬間的I/O洪水。
