iostat命令

壹頁書發表於2016-05-15
iOS
轉載自:
http://www.cnblogs.com/peida/archive/2012/12/28/2837345.html

Linux系統中的 iostat是I/O statistics（輸入/輸出統計）的縮寫，iostat工具將對系統的磁碟操作活動進行監視。它的特點是彙報磁碟活動統計情況，同時也會彙報出CPU使用情況。同vmstat一樣，iostat也有一個弱點，就是它不能對某個程式進行深入分析，僅對系統的整體情況進行分析。iostat屬於sysstat軟體包。可以用yum install sysstat 直接安裝。

1．命令格式：
iostat[引數][時間][次數]

2．命令功能：
  通過iostat方便檢視CPU、網路卡、tty裝置、磁碟、CD-ROM 等等裝置的活動情況, 負載資訊。

3．命令引數：
-C 顯示CPU使用情況
-d 顯示磁碟使用情況
-k 以 KB 為單位顯示
-m 以 M 為單位顯示
-N 顯示磁碟陣列(LVM) 資訊
-n 顯示NFS 使用情況
-p[磁碟] 顯示磁碟和分割槽的情況
-t 顯示終端和CPU的資訊
-x 顯示詳細資訊
-V 顯示版本資訊



cpu屬性值說明：
%user：CPU處在使用者模式下的時間百分比。
%nice：CPU處在帶NICE值的使用者模式下的時間百分比。
%system：CPU處在系統模式下的時間百分比。
%iowait：CPU等待輸入輸出完成時間的百分比。
%steal：管理程式維護另一個虛擬處理器時，虛擬CPU的無意識等待時間百分比。
%idle：CPU空閒時間百分比。

備註：如果%iowait的值過高，表示硬碟存在I/O瓶頸，%idle值高，表示CPU較空閒，如果%idle值高但系統響應慢時，有可能是CPU等待分配記憶體，此時應加大記憶體容量。%idle值如果持續低於10，那麼系統的CPU處理能力相對較低，表明系統中最需要解決的資源是CPU。

disk屬性值說明：
rrqm/s:  每秒進行 merge 的讀運算元目。即 rmerge/s
wrqm/s:  每秒進行 merge 的寫運算元目。即 wmerge/s
r/s:  每秒完成的讀 I/O 裝置次數。即 rio/s
w/s:  每秒完成的寫 I/O 裝置次數。即 wio/s
rsec/s:  每秒讀扇區數。即 rsect/s
wsec/s:  每秒寫扇區數。即 wsect/s
rkB/s:  每秒讀K位元組數。是 rsect/s 的一半，因為每扇區大小為512位元組。
wkB/s:  每秒寫K位元組數。是 wsect/s 的一半。
avgrq-sz:  平均每次裝置I/O操作的資料大小 (扇區)。
avgqu-sz:  平均I/O佇列長度。
await:  平均每次裝置I/O操作的等待時間 (毫秒)。
svctm: 平均每次裝置I/O操作的服務時間 (毫秒)。
%util:  一秒中有百分之多少的時間用於 I/O 操作，即被io消耗的cpu百分比
備註：如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁碟可能存在瓶頸。如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時間；如果 await 遠大於 svctm，說明I/O 佇列太長，io響應太慢，則需要進行必要優化。如果avgqu-sz比較大，也表示有當量io在等待。

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 洪水。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29254281/viewspace-2100232/，如需轉載，請註明出處，否則將追究法律責任。

相關文章