linux 系統監控、診斷工具之 IO wait

阿新 • • 發佈：2022-04-28

1、問題：

最近在做日誌的實時同步，上線之前是做過單份線上日誌壓力測試的，訊息佇列和客戶端、本機都沒問題，但是沒想到上了第二份日誌之後，問題來了：

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

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

2、排查：

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

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

PS：如果你對 top 的用法不瞭解，請參考我去年寫的一篇博文：

linux 系統監控、診斷工具之 top 詳解

常用組合方式有如下幾種：

用vmstat、sar、iostat檢測是否是CPU瓶頸
用free、vmstat檢測是否是記憶體瓶頸
用iostat、dmesg 檢測是否是磁碟I/O瓶頸
用netstat檢測是否是網路頻寬瓶頸

2.1 vmstat

vmstat命令的含義為顯示虛擬記憶體狀態（“Viryual 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來取代傳統的機械硬碟。不過前面也說了，我們從軟硬體兩方面著手的目的就是看能否分別尋求代價最小的解決方案：

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

3、最後的話：另闢蹊徑

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

我們知道程序有如下幾種狀態：

PROCESS STATE CODES
 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 而造成所謂的”非中斷睡眠“，我們可以從這點入手然後一步步的定位問題：

for x in `seq 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done
 D 248 [jbd2/dm-0-8]
 D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
 ----
 D 22 [kdmflush]
 D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
 ----
# 或者：
while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
 Tue Aug 23 20:03:54 CLT 2011
 root       302  0.0  0.0      0     0 ?        D    May22   2:58  _ [kdmflush]
 root       321  0.0  0.0      0     0 ?        D    May22   4:11  _ [jbd2/dm-0-8]
 Tue Aug 23 20:03:55 CLT 2011
 Tue Aug 23 20:03:56 CLT 2011

cat /proc/16528/io
 rchar: 48752567
 wchar: 549961789
 syscr: 5967
 syscw: 67138
 read_bytes: 49020928
 write_bytes: 549961728
 cancelled_write_bytes: 0
 
lsof -p 16528
 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
 bonnie++ 16528 root cwd DIR 252,0 4096 130597 /tmp
 <truncated>
 bonnie++ 16528 root 8u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 9u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 10u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 11u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 12u REG 252,0 501219328 131869 <strong>/tmp/Bonnie.16528</strong>
 
df /tmp
 Filesystem 1K-blocks Used Available Use% Mounted on
 /dev/mapper/workstation-root 7667140 2628608 4653920 37% /
 
fuser -vm /tmp
        USER        PID ACCESS COMMAND
 /tmp:  db2fenc1   1067 ....m db2fmp
        db2fenc1   1071 ....m db2fmp
        db2fenc1   2560 ....m db2fmp
        db2fenc1   5221 ....m db2fmp

4、Refer：

[1] Troubleshooting High I/O Wait in Linux ——A walkthrough on how to find processes that are causing high I/O Wait on Linux Systems http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/

[2] 理解Linux系統負荷

http://www.ruanyifeng.com/blog/2011/07/linux_load_average_explained.html

[3] 24 iostat, vmstat and mpstat Examples for Linux Performance Monitoring

http://www.thegeekstuff.com/2011/07/iostat-vmstat-mpstat-examples/

[4] vmstat vmstat命令 http://man.linuxde.net/vmstat

[5] Linux vmstat命令實戰詳解

http://www.cnblogs.com/ggjucheng/archive/2012/01/05/2312625.html [6] 影響Linux伺服器效能的因素

http://www.rocklv.net/2004/news/article_284.html

[7] linux磁碟IO檢視iostat,vmstat

http://blog.csdn.net/qiudakun/article/details/4699587

[8] What Process is using all of my disk IO

http://stackoverflow.com/questions/488826/what-process-is-using-all-of-my-disk-io