Linux系統出現了效能問題，一般我們可以透過top、iostat、free、vmstat等命令來檢視初步定位問題。其中iostat可以提供更豐富的IO效能狀態資料。
1. 基本使用
$iostat -d -k 1 10
引數 -d 表示，顯示裝置（磁碟）使用狀態；-k某些使用block為單位的列強制使用Kilobytes為單位；1 10表示，資料顯示每隔1秒重新整理一次，共顯示10次。
$iostat -d -k 1 10
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 39.29 21.14 1.44 441339807 29990031
sda1 0.00 0.00 0.00 1623 523
sda2 1.32 1.43 4.54 29834273 94827104
sda3 6.30 0.85 24.95 17816289 520725244
sda5 0.85 0.46 3.40 9543503 70970116
sda6 0.00 0.00 0.00 550 236
sda7 0.00 0.00 0.00 406 0
sda8 0.00 0.00 0.00 406 0
sda9 0.00 0.00 0.00 406 0
sda10 60.68 18.35 71.43 383002263 1490928140
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 327.55 5159.18 102.04 5056 100
sda1 0.00 0.00 0.00 0 0
tps：該裝置每秒的傳輸次數（Indicate the number of transfers per second that were issued to the device.）。“一次傳輸”意思是“一次I/O請求”。多個邏輯請求可能會被合併為“一次I/O請求”。“一次傳輸”請求的大小是未知的。
kB_read/s：每秒從裝置（drive expressed）讀取的資料量；kB_wrtn/s：每秒向裝置（drive expressed）寫入的資料量；kB_read：讀取的總資料量；kB_wrtn：寫入的總數量資料量；這些單位都為Kilobytes。
上面的例子中，我們可以看到磁碟sda以及它的各個分割槽的統計資料，當時統計的磁碟總TPS是39.29，下面是各個分割槽的TPS。（因為是瞬間值，所以總TPS並不嚴格等於各個分割槽TPS的總和）
2. -x 引數
使用-x引數我們可以獲得更多統計資訊。
iostat -d -x -k 1 10
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 1.56 28.31 7.80 31.49 42.51 2.92 21.26 1.46 1.16 0.03 0.79 2.62 10.28
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 2.00 20.00 381.00 7.00 12320.00 216.00 6160.00 108.00 32.31 1.75 4.50 2.17 84.20
rrqm/s：每秒這個裝置相關的讀取請求有多少被Merge了（當系統呼叫需要讀取資料的時候，VFS將請求發到各個FS，如果FS發現不同的讀取請求讀取的是相同Block的資料，FS會將這個請求合併Merge）；wrqm/s：每秒這個裝置相關的寫入請求有多少被Merge了。
rsec/s：每秒讀取的扇區數；wsec/：每秒寫入的扇區數。r/s：The number of read requests that were issued to the device per second；w/s：The number of write requests that were issued to the device per second；
await：每一個IO請求的處理的平均時間（單位是微秒毫秒）。這裡可以理解為IO的響應時間，一般地系統IO響應時間應該低於5ms，如果大於10ms就比較大了。
%util：在統計時間內所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該裝置有0.8秒在處理IO，而0.2秒閒置，那麼該裝置的%util = 0.8/1 = 80%，所以該引數暗示了裝置的繁忙程度。一般地，如果該引數是100%表示裝置已經接近滿負荷執行了（當然如果是多磁碟，即使%util是100%，因為磁碟的併發能力，所以磁碟使用未必就到了瓶頸）。
3. -c 引數
iostat還可以用來獲取cpu部分狀態值：
iostat -c 1 10
avg-cpu: %user %nice %sys %iowait %idle
1.98 0.00 0.35 11.45 86.22
avg-cpu: %user %nice %sys %iowait %idle
1.62 0.00 0.25 34.46 63.67
4. 常見用法
$iostat -d -k 1 10 #檢視TPS和吞吐量資訊
iostat -d -x -k 1 10 #檢視裝置使用率（%util）、響應時間（await）
iostat -c 1 10 #檢視cpu狀態
5. 例項分析
$iostat -d -k 1 |grep sda10
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda10 60.72 18.95 71.53 395637647 1493241908
sda10 299.02 4266.67 129.41 4352 132
sda10 483.84 4589.90 4117.17 4544 4076
sda10 218.00 3360.00 100.00 3360 100
sda10 546.00 8784.00 124.00 8784 124
sda10 827.00 13232.00 136.00 13232 136
上面看到，磁碟每秒傳輸次數平均約400；每秒磁碟讀取約5MB，寫入約1MB。
iostat -d -x -k 1
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 1.56 28.31 7.84 31.50 43.65 3.16 21.82 1.58 1.19 0.03 0.80 2.61 10.29
sda 1.98 24.75 419.80 6.93 13465.35 253.47 6732.67 126.73 32.15 2.00 4.70 2.00 85.25
sda 3.06 41.84 444.90 54.08 14204.08 2048.98 7102.04 1024.49 32.57 2.10 4.21 1.85 92.24
可以看到磁碟的平均響應時間<5ms，磁碟使用率>80。磁碟響應正常，但是已經很繁忙了。
延伸：
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 的速度和響應時間.