另闢蹊徑-診斷工具之 IO wait

叢集中的某臺機器 top 看到負載巨高，叢集中的機器硬體配置一樣，部署的軟體都一樣，卻單單這一臺負載有問題，初步猜測可能硬體有問題了。

同時，我們還需要把負載有異常的罪魁禍首揪出來，到時候從軟體、硬體層面分別尋找解決方案。

從 top 中可以看到 load average 偏高，%wa 很高，%us 偏低：

從上圖我們大致可以推斷 IO 遇到了瓶頸，下面我們可以再用相關的 IO 診斷工具，具體的驗證排查下。

常用組合方式有如下幾種：
•用vmstat、sar、iostat檢測是否是CPU瓶頸
•用free、vmstat檢測是否是記憶體瓶頸
•用iostat、dmesg 檢測是否是磁碟I/O瓶頸
•用netstat檢測是否是網路頻寬瓶頸

vmstat 的含義為顯示虛擬記憶體狀態（“Virtual Memor Statics”），但是它可以報告關於程式、記憶體、I/O等系統整體執行狀態。

它的相關欄位說明如下：

Procs（程式）
•r: 執行佇列中程式數量，這個值也可以判斷是否需要增加CPU。（長期大於1）
•b: 等待IO的程式數量，也就是處在非中斷睡眠狀態的程式數，展示了正在執行和等待CPU資源的任務個數。當這個值超過了CPU數目，就會出現CPU瓶頸了

Memory（記憶體）
•swpd: 使用虛擬記憶體大小，如果swpd的值不為0，但是SI，SO的值長期為0，這種情況不會影響系統效能。
•free: 空閒實體記憶體大小。
•buff: 用作緩衝的記憶體大小。
•cache: 用作快取的記憶體大小，如果cache的值大的時候，說明cache處的檔案數多，如果頻繁訪問到的檔案都能被cache處，那麼磁碟的讀IO bi會非常小。

Swap（交換區）
•si: 每秒從交換區寫到記憶體的大小，由磁碟調入記憶體。
•so: 每秒寫入交換區的記憶體大小，由記憶體調入磁碟。

注意：記憶體夠用的時候，這2個值都是0，如果這2個值長期大於0時，系統效能會受到影響，磁碟IO和CPU資源都會被消耗。有些朋友看到空閒記憶體（free）很少的或接近於0時，就認為記憶體不夠用了，不能光看這一點，還要結合si和so，如果free很少，但是si和so也很少（大多時候是0），那麼不用擔心，系統效能這時不會受到影響的。

IO（輸入輸出）

（現在的 版本塊的大小為1kb）
•bi: 每秒讀取的塊數
•bo: 每秒寫入的塊數

注意：隨機磁碟讀寫的時候，這2個值越大（如超出1024k)，能看到CPU在IO等待的值也會越大。

system（系統）
•in: 每秒中斷數，包括時鐘中斷。
•cs: 每秒上下文切換數。

注意：上面2個值越大，會看到由核心消耗的CPU時間會越大。

CPU

（以百分比表示）
•us: 使用者程式執行時間百分比(user time)。us的值比較高時，說明使用者程式消耗的CPU時間多，但是如果長期超50%的使用，那麼我們就該考慮最佳化程式演算法或者進行加速。
•sy: 核心系統程式執行時間百分比(system time)。sy的值高時，說明系統核心消耗的CPU資源多，這並不是良性表現，我們應該檢查原因。
•wa: IO等待時間百分比。wa的值高時，說明IO等待比較嚴重，這可能由於磁碟大量作隨機訪問造成，也有可能磁碟出現瓶頸（塊操作）。
•id: 空閒時間百分比

從 vmstat 中可以看到，CPU大部分的時間浪費在等待IO上面，可能是由於大量的磁碟隨機訪問或者磁碟的頻寬所造成的，bi、bo 也都超過 1024k，應該是遇到了IO瓶頸。

下面再用更加專業的磁碟 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的單位為毫秒)

可以看到兩塊硬碟中的 sdb 的利用率已經 100%，存在嚴重的 IO 瓶頸，下一步我們就是要找出哪個程式在往這塊硬碟讀寫資料。

根據 iotop 的結果，我們迅速的定位到是 flume 程式的問題，造成了大量的 IO wait。

但是在開頭我已經說了，叢集中的機器配置一樣，部署的程式也都 rsync 過去的一模一樣，難道是硬碟壞了？

這得找運維同學來查證了，最後的結論是：

Sdb為雙盤raid1，使用raid卡為“LSI Logic / Symbios Logic SAS1068E”，無cache。近400的IOPS壓力已經達到了硬體極限。而其它機器使用的raid卡是“LSI Logic / Symbios Logic MegaRAID SAS 1078”，有256MB cache，並未達到硬體瓶頸，解決辦法是更換能提供更大IOPS的機器，比如最後我們換了一臺帶 PERC6/i 整合RAID控制器卡的機器。需要說明的是，raid資訊是在raid卡和磁碟韌體裡面各存一份，磁碟上的raid資訊和raid卡上面的資訊格式要是匹配的，否則raid卡識別不了就需要格式化磁碟。

IOPS本質上取決於磁碟本身，但是又很多提升IOPS的方法，加硬體cache、採用RAID陣列是常用的辦法。如果是DB那種IOPS很高的場景，現在流行用SSD來取代傳統的機械硬碟。

不過前面也說了，我們從軟硬體兩方面著手的目的就是看能否分別尋求代價最小的解決方案：

知道硬體的原因了，我們可以嘗試把讀寫操作移到另一塊盤，然後再看看效果：

其實，除了用上述專業的工具定位這個問題外，我們可以直接利用程式狀態來找到相關的程式。

我們知道程式有如下幾種狀態：
•D uninterruptible sleep (usually IO)
•R running or runnable (on run queue)
•S interruptible sleep (waiting for an event to complete)
•T stopped, either by a job control signal or because it is being traced.
•W paging (not valid since the 2.6.xx kernel)
•X dead (should never be seen)
•Z defunct ("zombie") process, terminated but not reaped by its parent.

其中狀態為 D 的一般就是由於 wait IO 而造成所謂的”非中斷睡眠“，我們可以從這點入手然後一步步的定位問題：