Linux的IO性能監控工具iostat詳解

Linux的IO性能監控工具iostat詳解   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 的速度和響應時間.