原文作者：Jon Buys

       跟蹤大型分散式系統的效能問題，從本質上來講是複雜的。應用為什麼慢？瓶頸在哪裡？以我的經驗，最主要的罪魁禍首之一是高IO等待（即high IO wait）。換一個地方用的話來說：每個人都只是在等待[翻譯參考文獻1]。

        高IO等待問題的第一個徵兆通常是系統平均負載。負載均衡的計算都是基於CPU利用率的，即使用或等待CPU的程序數目，當然，在Linux平臺上，程序幾乎都處於不可中斷的睡眠狀態。負載均衡的基線可以解釋為，在一個CPU核的機器上上，該CPU得到充分利用。因此，對於4核機器中，如果系統平均複雜為4，表示該機器有足夠的資源來處理它需要做的工作，當然只是勉強。在相同的4

        如果系統顯示平均負載較高，但是CPU的系統(system)和使用者(user)利用率較低，那麼就需要觀察IO等待(即IO wait)。在linuc系統上，IO wait對系統負載有較大的影響，主要因為一個或多個核都可能被磁碟IO或網路IO所阻塞，只有當磁碟IO或網路IO完成後，這些核上的任務(即程序)才能進行下去。而這些程序使用ps aux來檢視均處於”D”狀態，即不可中斷的睡眠狀態。

        發現程序在等待IO完成是一回事，驗證高IO wait的原因是另一回事。使用”iostat –x 1”

[[email protected]~]$ iostat -x 1

         Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util

         cciss/c0d0        0.08     5.94  1.28  2.75    17.34    69.52    21.60     0.11   26.82   4.12   1.66

         cciss/c0d0p1      0.00     0.00  0.00  0.00     0.00     0.00     5.30     0.00    8.76   5.98   0.00

         cciss/c0d0p2      0.00     0.00  0.00  0.00     0.00     0.00    58.45     0.00    7.79   3.21   0.00

         cciss/c0d0p3      0.08     5.94  1.28  2.75    17.34    69.52    21.60     0.11  26.82   4.12   1.66

        由上可知，很明顯，裝置/dev/cciss/c0d0p3的等待時間很長。然而，我們並沒有掛載找個裝置，實際上，它是個LVM裝置。如果您使用的是LVM作為儲存，那麼，您應該發現iostat應該有那麼一點混亂。LVM使用device mapper子系統將檔案系統對映到物理裝置，因此，iostat可能顯示多個裝置，比如/ dev/dm-0和/ dev/dm-1。而”df –h”的輸出卻不會顯示device mapper路徑，而是列印了LVM路徑。最簡單的方法是在iostat引數中新增選項”-N”。

[[email protected]~]$ iostat -xN 1

         Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util

         vg1-root          0.00     0.00  0.09  3.01     0.85    24.08     8.05     0.08   24.69   1.79   0.55

         vg1-home          0.00     0.00  0.05  1.46     0.97    11.69     8.36     0.03   19.89   3.76   0.57

         vg1-opt           0.00     0.00  0.03  1.56     0.46    12.48     8.12     0.05   29.89   3.53   0.56

         vg1-tmp           0.00     0.00  0.00  0.06     0.00     0.45     8.00     0.00   24.85   4.90   0.03

         vg1-usr           0.00     0.00  0.63  1.41     5.85    11.28     8.38     0.07  32.48   3.11   0.63

         vg1-var           0.00     0.00  0.55  1.19     9.21     9.54    10.74     0.04   24.10   4.24   0.74

         vg1-swaplv        0.00     0.00  0.00  0.00     0.00     0.00     8.00     0.00    3.98   1.88   0.00

        為簡便起見，裁剪上面iostat命令的輸出資訊。列出的每個檔案系統所顯示出的IO等待都是不可接受的，觀察第十欄標有“await”的資料。相比而言，檔案系統/usr的await時間要高一些。我們先來分析一下這個檔案系統，使用命令” fuser -vm /opt ”檢視哪些程序在訪問這個檔案系統，程序列表如下。

[email protected]:/root > fuser -vm /opt

USER        PID ACCESS COMMAND
db2fenc1   1067 ....m db2fmp
db2fenc1   1071 ....m db2fmp
db2fenc1   2560 ....m db2fmp
db2fenc1   5221 ....m db2fmp

       當前伺服器上有112個DB2程序正在訪問/opt檔案系統，為簡便起見，列出四項。看來已經找到導致問題的原因，在伺服器上，資料庫配置為可使用速度更快的SAN訪問，作業系統可以使用的是本地磁碟。可以打電話問問DBA(資料庫管理員)怎麼做才能這樣配置。
最後一個組要的注意的是LVM和device mapper。 “Iostat –xN”命令的輸出顯示的是邏輯卷名，但它是可以通過命令”ls –lrt / dev /mapper”查到對映關係表。輸出資訊的第六列中的dm-是與iostat中的裝置名相對應的。
有時候，在作業系統或應用層是沒有什麼可以做的，除了選擇速度更快的磁碟，並沒有其他的選擇。幸運的是，快速磁碟訪問，如SAN或SSD的價格正在逐步下降。
最後一個需要注意的，具體問題具體分析。您需要深刻了解您能的環境，包括物理環境，虛擬環境和應用層架構，這樣才能便於診斷問題。如果有其他方法或方式來解決這類問題，我很想聽聽這些意見。
 

翻譯參考文獻

[1] http://www.goodreads.com/quotes/376564-waiting-for-the-fish-to-bite-or-waiting-for-wind

“Waiting for the fish to bite or waiting for wind to fly a kite. Or waiting around for Friday night or waiting perhaps for their Uncle Jake or a pot to boil or a better break or a string of pearls or a pair of pants or a wig with curls or another chance. Everyone is just waiting.”

 ----------------------------------------

初次翻譯，不足之處，請不吝賜教

----------------------------------------