當前位置：首頁 > 编程资源 > 综合教程 >内容正文

综合教程

Linux 高 wio 分析

發布時間：2024/1/4 综合教程 47 生活家

生活随笔收集整理的這篇文章主要介紹了 Linux 高 wio 分析小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

High IO wait

1. 現象
2. 分析

2.1. iotop或者pidstat

2.1.1. iotop
2.1.2. pidstat

2.2. 腳本
2.3. 追蹤進程

1 現象

top 命令，我們發現%wa 的值,達到20以上,甚至40以上，此時，我們就要明確，現在CPU 大量消耗在等待IO響應上了。請注意，是在等待IO響應，而不是在等待磁盤完成IO操作.

這兩者之間的區別在于，等待IO響應，可能鏈路沒反應，請求根本沒有到達磁盤，也有可能磁盤損壞，無法響應，高IO wait 不一定代表磁盤很忙。

因此分析這種情況，我們需要從兩個角度來考慮: 磁盤忙和磁盤不忙。磁盤不忙，但是 %wa 較高，唯一說明的問題就是:IO通道發生了異常。進程發送請求、信號傳輸、鏈路傳輸、磁盤讀取/寫入、信號返回等各個步驟都有可能異常。所以%wa高，不一定是磁盤達到了瓶頸。也有可能是鏈路或存儲本身出現了問題,也有可能服務器參數配置不合理導致進程無法發送消息。

2 分析

常用的分析工具有iotop,iostat. 一般想看哪個或者哪些磁盤上CPU等待比較高，會使用iostat, 而查找消耗IO較高的進程則使用iotop. 那么如果我們查看哪些進程在等待IO響應,可以使用一行命令。下面來詳細說明:

2.1 iotop或者pidstat

2.1.1 iotop

iotop可以讓我們很方便的找出哪個進程在消耗大量的IO資源。也就是統計出進程的IO量。這個命令的統計結果，是真實的IO消耗的統計,一般排行在靠前的進程，說明消耗IO資源較多。具體磁盤忙不忙，還要看IO吞吐量。示例如下:

Total DISK READ :       0.00 B/s | Total DISK WRITE :     137.02 K/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:     207.49 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 5965 be/4 adb         0.00 B/s   62.64 K/s  0.00 %  0.28 % postgres: wal writer process
 5908 be/4 adb         0.00 B/s   15.66 K/s  0.00 %  0.00 % postgres: logger process
 5952 be/4 adb         0.00 B/s   11.74 K/s  0.00 %  0.00 % postgres: logger process
 5953 be/4 adb         0.00 B/s   15.66 K/s  0.00 %  0.00 % postgres: logger process
 5967 be/4 adb         0.00 B/s   15.66 K/s  0.00 %  0.00 % postgres: stats collector process
 ........

輸出結果以IO列做降序排列，固定的時間(默認1秒)間隔刷新一次結果。有了進程編號，我們就可以很方便的分析，定位高IO產生的原因。 或者直接輸入 iotop -boP 命令, 將每秒輸出一次IO統計和正在使用IO的進程。如果使用IO的進程較多，還是不加參數方便

不過有些環境，并沒有安裝iotop工具,那么我們怎么辦？其實iotop命令，獲取的數據就是存儲在/proc/<pid>/io文件中。比如:

#cat /proc/5977/io
rchar: 29381
wchar: 4369248962
syscr: 29379
syscw: 96033
read_bytes: 0
write_bytes: 4369088512
cancelled_write_bytes: 0

我們完全可以通過自己寫腳本來實現基本的統計，比如每秒哪個進程讀寫最高。

2.1.2 pidstat

pidstat 這個命令，也是可以用來做高IO等待的性能分析的。而且也非常方便實用。

我們可以通過 pidstat -d <interval> 來輸出進程的消耗情況。

pidstat -d 1 1
12時56分51秒       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
12時56分53秒      3348      0.00     20.00      0.00  jbd2/dm-2-8
12時56分53秒      3679      0.00      6.00      0.00  rsyslogd
12時56分53秒     22903      0.00    724.00      0.00  ns-slapd
12時56分53秒     44188      0.00     18.00      0.00  java
12時56分53秒     47980      0.00      4.00      0.00  java

也可以進行條件判斷，取出關心的數據。比如:

pidstat -dl| head -3;pidstat -dl |awk '{if ($4 >10 || $3 > 10) print $0}'

這一行的本意是輸出讀或者寫大于10K的進程，但是由于不同操作系統設置不同，讀和寫的列不一定是第3和第4列。因此執行前，需要先確認。

notepidstat -d 的輸出，默認是以Pid 進行升序排列的。

2.2 腳本

等待I/O的進程通過處于uninterruptible sleep或D狀態。通過這個特點，查找有問題的進程。這行命令，找出來的進程，只能說明，進程在等待IO操作，但是并不能說明磁盤本身已經達到瓶頸。但是從另外一個角度來講，我們可以定準有問題的進程。

for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done

此命令，每5秒, 取一次結果.查詢結果類似如下:

-----
D 248 [jbd2/dm-0-8]
-----
D 248 [jbd2/dm-0-8]

2.3 追蹤進程

我們定位了等待IO請求的進程，如果確實是消耗了IO, 我們可以通過減少單位時間的 IO吞吐來解決，或者把數據分散到不同的時間段去處理。

如果進程只是在等待IO，并沒有什么吞吐量，可以對進程進行追蹤(strace/truss)或者gdb調試?？纯磫栴}到底出現在哪里。問題到底出在哪兒。

Author: halberd.lee@gmail.com

Created: 2020-04-29 Wed 17:49

Validate

總結

以上是生活随笔為你收集整理的Linux 高 wio 分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

linux
wio