| 導讀 | 最近在做日誌的即時同步，上線之前是做過單份線上日誌壓力測試的，訊息佇列和客戶端、本機都沒問題，但是沒想到上了第二份日誌之後，問題來了： |
叢集中的某台機器 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（輸入輸出）
（現在的Linux版本區塊的大小為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瓶頸。
2.2 iostat下面再用更專業的磁碟 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 瓶頸，下一步我們就是要找出哪個程序在往這塊硬碟上讀寫資料。
2.3 iotop
#根據 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 或 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 而造成所謂的”非中斷睡眠“，我們可以從這點入手然後一步步的定位問題：
以上是探索全新路徑-IO等待的診斷工具的詳細內容。更多資訊請關注PHP中文網其他相關文章！
