iostat命令用途：主要用於監控系統設備的IO負載情況，iostat首次運行時顯示自系統啟動開始的各項統計信息，之後運行iostat將顯示自上次運行該命令以後的統計信息。用戶可以通過指定統計的次數和時間來獲得所需的統計信息。iostat有一個弱點，就是它不能對某個進程進行深入分析，僅對系統的整體情 ...
iostat命令
用途：主要用於監控系統設備的IO負載情況，iostat首次運行時顯示自系統啟動開始的各項統計信息，之後運行iostat將顯示自上次運行該命令以後的統計信息。用戶可以通過指定統計的次數和時間來獲得所需的統計信息。
iostat有一個弱點，就是它不能對某個進程進行深入分析，僅對系統的整體情況進行分析。iostat屬於sysstat軟體包。可以用yum install sysstat 直接安裝。
命令格式：
iostat[參數][時間][次數]
命令參數： • -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。
磁碟每一列的含義如下:
• 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 操作的等待時間(毫秒)
• r_await：每個讀操作平均所需的時間=[Δrd_ticks/Δrd_ios]
不僅包括硬碟設備讀操作的時間，還包括了在kernel隊列中等待的時間。
• w_await：每個寫操作平均所需的時間=[Δwr_ticks/Δwr_ios]
不僅包括硬碟設備寫操作的時間，還包括了在kernel隊列中等待的時間。
• svctm: 平均每次設備 I/O 操作的服務時間(毫秒)
• %util: 一秒中有百分之多少的時間用於 I/O 操作,或者說一秒中有多少時間 I/O 隊列是非空的。
備註：
• 如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁碟可能存在瓶頸。
• 如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時間；
• 如果 await 遠大於 svctm，說明I/O 隊列太長，io響應太慢，則需要進行必要優化。
• 如果avgqu-sz比較大，也表示有當量io在等待。
對於以上示例輸出，可以獲取到以下信息： 1. 每秒向磁碟上寫13M左右數據(wkB/s值) 2. 每秒有28次IO操作(r/s+w/s)，其中以寫操作為主體 3. 平均每次IO請求等待處理的時間為82.19毫秒，處理耗時為15.66毫秒 4. 等待處理的IO請求隊列中，平均有0.1個請求駐留 以上各值之間也存在聯繫，可以由一些值計算出其他數值，例如： util = (r/s+w/s) * (svctm/1000)
怎麼理解這裡的欄位呢?
以超市結賬的例子來說明。 我們在超市排隊結賬時,怎麼決定該去哪個收銀台呢? 首先是看每個收銀台的排隊人數,5 個人總比 20 人要快吧?
除了數人頭,我們也常常看看前面人購買的東西多少,如果前面有個採購了一星期食品的大媽, 那麼可以考慮換個隊排了。
還有就是收銀員的速度了,如果碰上了連錢都點不清楚的新手,那就有的等了。
另外,時機也很重要,可能 5 分鐘前還人滿為患的收款台,現在已是人去樓空,這時候交款就很爽啊,當然,前提是那過去的 5 分鐘里所做的事情比排隊要有意義(不過我還沒發現什麼事情比排隊還無聊的)。
I/O 系統也和超市排隊有很多類似之處:
• r/s+w/s 類似於交款人的總數
• avgqu-sz(平均隊列長度): 類似於單位時間里平均排隊的人數
• svctm(平均服務時間) 類似於收銀員的收款速度
• await(平均等待時間) 類似於平均每人的等待時間
• avgrq-sz(平均 IO 數據) 類似於平均每人所買的東西多少
• %util(磁碟 IO 使用率) 類似於收款台前有人排隊的時間比例。
可以根據這些數據分析出 I/O 請求的模式,以及 I/O 的速度和響應時間:
• 如果%util 接近 100%,說明產生的 I/O 請求太多,I/O 系統已經滿負荷,該磁碟可能存在瓶頸。
• svctm 的大小一般和磁碟性能有關,CPU/記憶體的負荷也會對其有影響,請求過多也會間接導致 svctm的增加。
• await 的大小一般取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。一般來說 svctm < await,因為同時等待的請求的等待時間被重覆計算了。如果 svctm 比較接近 await,說明 I/O 幾乎沒有等待時間
• 如果 await 遠大於 svctm,說明 I/O 隊列太長,應用得到的響應時間變慢
• 隊列長度(avgqu-sz)也可作為衡量系統 I/O 負荷的指標,但由於 avgqu-sz 是按照單位時間的平均值,所以不能反映瞬間的 I/O 洪水。
• 如果響應時間超過了用戶可以容許的範圍,這時可以考慮更換更快的磁碟,調整內核 elevator 演算法,優化應用,或者升級 CPU。
• 如果%util 很大,而 rkB/s 和 wkB/s 很小,一般是因為磁碟存在較多的磁碟隨機讀寫,最好把磁碟隨機讀寫優化成順序讀寫。
鏈接：https://www.linuxidc.com/Linux/2016-12/138242.htm
