iostat使用與總結
1、iostat命令介紹
對於I/O-bond類型的進程，我們經常用iostat工具查看進程IO請求下發的數量、系統處理IO請求的耗時，進而分析進程與操作系統的交互過程中IO方面是否存在瓶頸。
2、iostat命令使用
下面通過iostat命令使用實例，說明使用iostat查看IO請求下發情況、系統IO處理能力的方法，以及命令執行結果中各字段的含義。
1).不加選項執行iostat
我們先來看直接執行iostat的輸出結果：
linux # iostat
Linux 2.6.16.60-0.21-smp (linux)
avg-cpu: %user %nice %system %iowait %steal %idle
0.07 0.00 0.05 0.06 0.00 99.81
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.58 9.95 37.47 6737006 25377400
sdb 0.00 0.00 0.00 824 0
單獨執行iostat，顯示的結果爲從系統開機到當前執行時刻的統計信息。以上輸出中，除最上面指示系統版本、主機名和日期的一行外，另有兩部分：
avg-cpu: 總體cpu使用情況統計信息，對於多核cpu，這裏爲所有cpu的平均值
avg-cpu段:
%user: 在用戶級別運行所使用的CPU的百分比.
%nice:優先進程消耗的CPU時間，佔所有CPU的百分比.
%system: 在系統級別(kernel)運行所使用CPU的百分比.
%iowait: CPU等待硬件I/O時,所佔用CPU百分比.
%steal: 管理程序維護另一個虛擬處理器時，虛擬CPU的無意識等待時間百分比。
%idle: CPU空閒時間的百分比.
Device: 各磁盤設備的IO統計信息
對於cpu統計信息一行，我們主要看iowait的值，它指示cpu用於等待io請求完成的時間Device 。中各列含義如下：
Device: 以sdX形式顯示的設備名稱
tps: 每秒進程下發的IO讀、寫請求數量
Blk_read/s: 每秒讀扇區數量(一扇區爲512bytes)
Blk_wrtn/s: 每秒寫扇區數量
Blk_read: 取樣時間間隔內讀扇區總數量
Blk_wrtn: 取樣時間間隔內寫扇區總數量
我們可以使用-c選項單獨顯示avg-cpu部分的結果，使用-d選項單獨顯示Device部分的信息。
2).指定採樣時間間隔與採樣次數
與sar命令一樣，我們可以以"iostat interval [count] ”形式指定iostat命令的採樣間隔和採樣次數：
linux # iostat -d 1 2
Linux 2.6.16.60-0.21-smp (linux) 06/13/12
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.55 8.93 36.27 6737086 27367728sdb 0.00 0.00 0.00 928 0
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 2.00 0.00 72.00 0 72
sdb 0.00 0.00 0.00 0 0
以上命令輸出Device的信息，採樣時間爲1秒，採樣2次，若不指定採樣次數，則iostat會一直輸出採樣信息，直到按”ctrl+c”退出命令。注意，第1次採樣信息與單獨執行iostat的效果一樣，爲從系統開機到當前執行時刻的統計信息。
3).以kB爲單位顯示讀寫信息(-k選項)
我們可以使用-k選項，指定iostat的部分輸出結果以kB爲單位，而不是以扇區數爲單位：
linux # iostat -d -k
Linux 2.6.16.60-0.21-smp (linux) 06/13/12
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0.55 4.46 18.12 3368543 13686096
sdb 0.00 0.00 0.00 464 0
以上輸出中，kB_read/s、kB_wrtn/s、kB_read和kB_wrtn的值均以kB爲單位，相比以扇區數爲單位，這裏的值爲原值的一半(1kB=512bytes*2)
4).更詳細的io統計信息(-x選項)
爲顯示更詳細的io設備統計信息，我們可以使用-x選項，在分析io瓶頸時，一般都會開啓-x選項：
linux # iostat -x -k -d 1
Linux 2.6.16.60-0.21-smp (linux) 06/13/12
……
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 9915.00 1.00 90.00 4.00 34360.00 755.25 11.79 120.57 6.33 57.60
以上各列的含義如下：
rrqm/s: 每秒對該設備的讀請求被合併次數，文件系統會對讀取同塊(block)的請求進行合併
wrqm/s: 每秒對該設備的寫請求被合併次數
r/s: 每秒完成的讀次數
w/s: 每秒完成的寫次數
rkB/s: 每秒讀數據量(kB爲單位)
wkB/s: 每秒寫數據量(kB爲單位)
avgrq-sz:平均每次IO操作的數據量(扇區數爲單位)
avgqu-sz: 平均等待處理的IO請求隊列長度
await: 平均每次IO請求等待時間(包括等待時間和處理時間，毫秒爲單位)
svctm: 平均每次IO請求的處理時間(毫秒爲單位)
%util: 採用週期內用於IO操作的時間比率，即IO隊列非空的時間比率
如果%util 接近100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸；idle小於70% IO壓力就較大了,一般讀取速度有較多的wait。
對於以上示例輸出，我們可以獲取到以下信息：
每秒向磁盤上寫30M左右數據(wkB/s值)
每秒有91次IO操作(r/s+w/s)，其中以寫操作爲主體
平均每次IO請求等待處理的時間爲120.57毫秒，處理耗時爲6.33毫秒
等待處理的IO請求隊列中，平均有11.79個請求駐留
以上各值之間也存在聯繫，我們可以由一些值計算出其他數值，例如：
util = (r/s+w/s) * (svctm/1000)
對於上面的例子有：util = (1+90)*(6.33/1000) = 0.57603
附註：
一般:
svctm < await (因爲同時等待的請求的等待時間被重複計算了)，
svctm的大小一般和磁盤性能有關:CPU/內存的負荷也會對其有影響，請求過多也會間接導致 svctm 的增加。
await: 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
/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 次設備 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。