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 10Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtnsda 39.29 21.14 1.44 441339807 29990031sda1 0.00 0.00 0.00 1623 523sda2 1.32 1.43 4.54 29834273 94827104sda3 6.30 0.85 24.95 17816289 520725244sda5 0.85 0.46 3.40 9543503 70970116sda6 0.00 0.00 0.00 550 236sda7 0.00 0.00 0.00 406 0sda8 0.00 0.00 0.00 406 0sda9 0.00 0.00 0.00 406 0sda10 60.68 18.35 71.43 383002263 1490928140Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtnsda 327.55 5159.18 102.04 5056 100sda1 0.00 0.00 0.00 0 0tps：該裝置每秒的傳輸次數（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 10Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %utilsda 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.28Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %utilsda 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.20rrqm/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 10avg-cpu: %user %nice %sys %iowait %idle1.98 0.00 0.35 11.45 86.22avg-cpu: %user %nice %sys %iowait %idle1.62 0.00 0.25 34.46 63.674. 常見用法$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 sda10Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtnsda10 60.72 18.95 71.53 395637647 1493241908sda10 299.02 4266.67 129.41 4352 132sda10 483.84 4589.90 4117.17 4544 4076sda10 218.00 3360.00 100.00 3360 100sda10 546.00 8784.00 124.00 8784 124sda10 827.00 13232.00 136.00 13232 136上面看到，磁碟每秒傳輸次數平均約400；每秒磁碟讀取約5MB，寫入約1MB。iostat -d -x -k 1Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %utilsda 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.29sda 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.25sda 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)/swrqm/s:  每秒進行 merge 的寫運算元目.即 delta(wmerge)/sr/s:           每秒完成的讀 I/O 裝置次數.即 delta(rio)/sw/s:         每秒完成的寫 I/O 裝置次數.即 delta(wio)/srsec/s:    每秒讀扇區數.即 delta(rsect)/swsec/s:  每秒寫扇區數.即 delta(wsect)/srkB/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 的速度和回應時間.