iowait 過高問題的查找及解決linux
Linux 有許多可用來查找問題的簡單工具，也有許多是更高級的
I/O Wait 就是一個需要使用高級的工具來debug的問題，當然也有許多基本工具的高級用法。I/O wait的問題難以定位的原因是因為我們有很多工具可以告訴你說I/O 受限了，但是並沒有告訴你具體是那個進程引起的（哪些進程們）
確認是否是I/O問題導致系統緩慢
確認是否是I/O導致的系統緩慢我們可以使用多個命令，但是，最簡單的是unix的命令 top
[root@localhost ~]# top top - 15:19:26 up 6:10, 4 users, load average: 0.00, 0.01, 0.05 Tasks: 147 total, 1 running, 146 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.3 sy, 0.0 ni, 99.7 id, 96.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 999936 total, 121588 free, 328672 used, 549676 buff/cache KiB Swap: 2097148 total, 2095792 free, 1356 used. 450460 avail Mem
從Cpu一行我們可以看到浪費在I/O Wait上的CPU百分比；這個數字越高說明越多的CPU資源在等待I/O權限
wa -- iowait AmountoftimetheCPUhasbeenwaitingfor I/O to complete.
查找哪塊磁盤正在被寫入
上邊的top命令從一個整體上說明了I/O wait，但是並沒有說明是哪塊磁盤影響的，想知道是哪塊磁盤引發的問題，我們用到了另外一個命令 iostat 命令
[root@localhost ~]# iostat -x 2 5
Linux 3.10.0-514.el7.x86_64 (localhost.localdomain) 2017年03月03日 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.34 0.00 0.31 0.01 0.00 99.33
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.05 1.16 0.17 39.00 17.38 84.60 0.00 2.17 0.87 11.14 0.65 111.41
scd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 0.64 0.64 0.00 0.64 0.00
dm-0 0.00 0.00 1.10 0.20 37.85 17.21 84.71 0.00 2.43 0.90 10.88 0.66 0.09
dm-1 0.00 0.00 0.01 0.02 0.07 0.08 9.70 0.00 1.42 0.27 2.05 0.09 0.00
上邊的例子中，iostat 會每2秒更新一次，一共打印5次信息， -x 的選項是打印出擴展信息
第一個iostat 報告會打印出系統最後一次啟動後的統計信息，這也就是說，在多數情況下，第一個打印出來的信息應該被忽略，剩下的報告，都是基於上一次間隔的時間。舉例子來說，這個命令會打印5次，第二次的報告是從第一次報告出來一個後的統計信息，第三次是基於第二次 ，依次類推
在上面的例子中，sda的%utilized 是111.41%，這個很好的說明了有進程正在寫入到sda磁盤中。
除了%utilized 外，我們可以得到更豐富的資源從iostat，例如每毫秒讀寫請求（rrqm/s & wrqm/s)），每秒讀寫的（(r/s & w/s)，當然還有更多。在上邊的例子中，我們的項目看起來正在讀寫非常多的信息。這個對我們查找相應的進程非常有用
查找引起高I/O wait 對應的進程
[root@localhost ~]# iotop
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1028 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % sshd
最簡單的方式來發現罪魁禍首是使用命令iotop，通過查看iotop的統計信息，我們可以很容易的指導sshd就是罪魁禍首
雖然iotop是一個非常強大的工具，並且使用簡單，但是它並不是默認安裝在所有的linux操作系統中。並且我個人傾向不要太依賴那些默認沒有安裝的命令。一個系統管理員可能會發現他無法立即安裝額外的除默認程序之外的軟件，除非等到後邊的維護的時間。
查找哪個文件引起的I/Owait
lsof 命令可以展示一個進程打開的所有文件，或者打開一個文件的所有進程。從這個列表中，我們可以找到具體是什麽文件被寫入，根據文件的大小和/proc中io文件的具體數據
我們可以使用-p <pid>的方式來減少輸出，pid是具體的進程
[root@localhost ~]# lsof -p 1028 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sshd 1028 root cwd DIR 253,0 233 64 / sshd 1028 root rtd DIR 253,0 233 64 / sshd 1028 root txt REG 253,0 819640 2393730 /usr/sbin/sshd sshd 1028 root mem REG 253,0 61752 180464 /usr/lib64/libnss_files-2.17.so sshd 1028 root mem REG 253,0 43928 180476 /usr/lib64/librt-2.17.so sshd 1028 root mem REG 253,0 15688 269136 /usr/lib64/libkeyutils.so.1.5 sshd 1028 root mem REG 253,0 62744 482870 /usr/lib64/libkrb5support.so.0.1 sshd 1028 root mem REG 253,0 11384 180425 /usr/lib64/libfreebl3.so sshd 1028 root mem REG 253,0 143352 180472 /usr/lib64/libpthread-2.17.so sshd 1028 root mem REG 253,0 251784 202440 /usr/lib64/libnspr4.so sshd 1028 root mem REG 253,0 20016 202441 /usr/lib64/libplc4.so sshd 1028 root mem REG 253,0 15768 202442 /usr/lib64/libplds4.so sshd 1028 root mem REG 253,0 182056 202443 /usr/lib64/libnssutil3.so sshd 1028 root mem REG 253,0 1220240 650074 /usr/lib64/libnss3.so sshd 1028 root mem REG 253,0 164048 650076 /usr/lib64/libsmime3.so sshd 1028 root mem REG 253,0 276752 650077 /usr/lib64/libssl3.so sshd 1028 root mem REG 253,0 121296 269112 /usr/lib64/libsasl2.so.3.0.0 sshd 1028 root mem REG 253,0 398264 202404 /usr/lib64/libpcre.so.1.2.0 sshd 1028 root mem REG 253,0 2116736 180446 /usr/lib64/libc-2.17.so sshd 1028 root mem REG 253,0 15848 202439 /usr/lib64/libcom_err.so.2.1 sshd 1028 root mem REG 253,0 202568 482862 /usr/lib64/libk5crypto.so.3.1 sshd 1028 root mem REG 253,0 959008 482868 /usr/lib64/libkrb5.so.3.3 sshd 1028 root mem REG 253,0 324888 482858 /usr/lib64/libgssapi_krb5.so.2.2 sshd 1028 root mem REG 253,0 110632 180474 /usr/lib64/libresolv-2.17.so sshd 1028 root mem REG 253,0 40640 180450 /usr/lib64/libcrypt-2.17.so sshd 1028 root mem REG 253,0 113152 180456 /usr/lib64/libnsl-2.17.so sshd 1028 root mem REG 253,0 90664 202424 /usr/lib64/libz.so.1.2.7 sshd 1028 root mem REG 253,0 14432 186432 /usr/lib64/libutil-2.17.so sshd 1028 root mem REG 253,0 61872 766946 /usr/lib64/liblber-2.4.so.2.10.3 sshd 1028 root mem REG 253,0 344280 766948 /usr/lib64/libldap-2.4.so.2.10.3 sshd 1028 root mem REG 253,0 19344 180452 /usr/lib64/libdl-2.17.so sshd 1028 root mem REG 253,0 2025472 482880 /usr/lib64/libcrypto.so.1.0.1e sshd 1028 root mem REG 253,0 23968 202508 /usr/lib64/libcap-ng.so.0.0.0 sshd 1028 root mem REG 253,0 155744 202421 /usr/lib64/libselinux.so.1 sshd 1028 root mem REG 253,0 61672 539049 /usr/lib64/libpam.so.0.83.1 sshd 1028 root mem REG 253,0 122936 202512 /usr/lib64/libaudit.so.1.0.0 sshd 1028 root mem REG 253,0 42520 298848 /usr/lib64/libwrap.so.0.7.6 sshd 1028 root mem REG 253,0 11328 568388 /usr/lib64/libfipscheck.so.1.2.1 sshd 1028 root mem REG 253,0 155064 180439 /usr/lib64/ld-2.17.so sshd 1028 root 0u CHR 1,3 0t0 5930 /dev/null sshd 1028 root 1u CHR 1,3 0t0 5930 /dev/null sshd 1028 root 2u CHR 1,3 0t0 5930 /dev/null sshd 1028 root 3u IPv4 21185 0t0 TCP *:ssh (LISTEN) sshd 1028 root 4u IPv6 21194 0t0 TCP *:ssh (LISTEN)
為了更深入的確認這些文件被頻繁的讀寫，我們可以通過如下命令來查看
[root@localhost ~]# df /tmp 文件系統 1K-塊 已用 可用 已用% 掛載點 /dev/mapper/cl-root 17811456 3981928 13829528 23% /
從上面的命令結果來看，我們可以確定/tmp 是我們環境的邏輯磁盤的根目錄
[root@localhost ~]# pvdisplay --- Physical volume --- PV Name /dev/sda2 VG Name cl PV Size 19.00 GiB / not usable 3.00 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 4863 Free PE 0 Allocated PE 4863 PV UUID 4QfaOy-DNSO-niK1-ayn2-K6AY-WZMy-9Nd2It
過pvdisplay我們能看到/dev/sda2其實就是我們用來創建邏輯磁盤的具體磁盤。通過以上的信息我們可以放心的說lsof的結果就是我們要查找的文件
iowait 過高問題的查找及解決linux