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

時間 2019-11-11

標籤 linux 系統監控診斷工具 wait 欄目 Linux 简体版

原文原文鏈接

一、問題：

最近在作日誌的實時同步，上線以前是作過單份線上日誌壓力測試的，消息隊列和客戶端、本機都沒問題，可是沒想到上了第二份日誌以後，問題來了：html

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

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

二、排查：

從 top 中能夠看到 load average 偏高，%wa 很高，%us 偏低：算法

從上圖咱們大體能夠推斷 IO 遇到了瓶頸，下面咱們能夠再用相關的 IO 診斷工具，具體的驗證排查下。緩存

PS：若是你對 top 的用法不瞭解，請參考我去年寫的一篇博文：性能優化

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

經常使用組合方式有以下幾種：網絡

用vmstat、sar、iostat檢測是不是CPU瓶頸app
用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來取代傳統的機械硬盤。
不過前面也說了，咱們從軟硬件兩方面着手的目的就是看可否分別尋求代價最小的解決方案：

知道硬件的緣由了，咱們能夠嘗試把讀寫操做移到另外一塊盤，而後再看看效果：

三、最後的話：另闢蹊徑

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

咱們知道進程有以下幾種狀態：

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

四、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