一、iostat和iowait詳細解說-查看磁盤瓶頸
一、iostat基礎
%iowait並不能反應磁盤瓶頸
1、安裝iostat
iostat的包名叫sysstat
yum install sysstat -y
2、iowait實際測量的是cpu時間：
%iowait = (cpu idle time)/(all cpu time)
說明：高速cpu會造成很高的iowait值，但這並不代表磁盤是系統的瓶頸。唯一能說明磁盤是系統瓶頸的方法，就是很高的read/write時間，一般來說超過20ms，就代表了不太正常的磁盤性能。為什么是20ms呢？一般來說，一次讀寫就是一次尋到+一次旋轉延遲+數據傳輸的時間。由於，現代硬盤數據傳輸就是幾微秒或者幾十微秒的事情，遠遠小於尋道時間2~20ms和旋轉延遲4~8ms，所以只計算這兩個時間就差不多了，也就是15~20ms。只要大於20ms，就必須考慮是否交給磁盤讀寫的次數太多，導致磁盤性能降低了。
二、iostat來對linux硬盤IO性能進行了解
1、iostat分析
使用其工具filemon來檢測磁盤每次讀寫平均耗時。在Linux下，可以通過iostat命令還查看磁盤性能。其中的svctm一項，反應了磁盤的負載情況，如果該項大於15ms，並且util%接近100%，那就說明，磁盤現在是整個系統性能的瓶頸了。
# iostat -x 1 Linux 3.10.0-514.26.2.el7.x86_64 (v01-ops-es03) 2018年06月27日 _x86_64_ (2 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 15.10 0.00 5.72 18.54 0.00 60.64 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.24 0.40 0.15 0.15 2.64 2.65 35.08 0.00 1.55 2.94 0.20 0.69 0.02 sdb 0.00 0.10 0.06 0.05 0.54 0.69 22.27 0.00 1.68 3.08 0.07 0.42 0.00
- 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的單位為毫秒)
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。
idle小於70% IO壓力就較大了,一般讀取速度有較多的wait。
同時可以結合vmstat 查看查看b參數(等待資源的進程數)和wa參數(IO等待所占用的CPU時間的百分比,高過30%時IO壓力高)
await 的參數也要多和 svctm 來參考。差的過高就一定有 IO 的問題。
avgqu-sz 也是個做 IO 調優時需要注意的地方，這個就是直接每次操作的數據的大小，如果次數多，但數據拿的小的話，其實 IO 也會很小.如果數據拿的大，才IO 的數據會高。也可以通過 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是講，讀定速度是這個來決定的。
另外還可以參考
svctm 一般要小於 await (因為同時等待的請求的等待時間被重復計算了)，svctm 的大小一般和磁盤性能有關，CPU/內存的負荷也會對其有影響，請求過多也會間接導致 svctm 的增加。await 的大小一般取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時間；如果 await 遠大於 svctm，說明 I/O 隊列太長，應用得到的響應時間變慢，如果響應時間超過了用戶可以容許的范圍，這時可以考慮更換更快的磁盤，調整內核 elevator 算法，優化應用，或者升級 CPU。
隊列長度(avgqu-sz)也可作為衡量系統 I/O 負荷的指標，但由於 avgqu-sz 是按照單位時間的平均值，所以不能反映瞬間的 I/O 洪水。
別人一個不錯的例子(I/O 系統 vs. 超市排隊)
舉一個例子，我們在超市排隊 checkout 時，怎么決定該去哪個交款台呢? 首當是看排的隊人數，5個人總比20人要快吧? 除了數人頭，我們也常常看看前面人購買的東西多少，如果前面有個采購了一星期食品的大媽，那么可以考慮換個隊排了。還有就是收銀員的速度了，如果碰上了連 錢都點不清楚的新手，那就有的等了。另外，時機也很重要，可能 5 分鍾前還人滿為患的收款台，現在已是人去樓空，這時候交款可是很爽啊，當然，前提是那過去的 5 分鍾里所做的事情比排隊要有意義 (不過我還沒發現什么事情比排隊還無聊的)。
2、I/O 系統也和超市排隊有很多類似之處:
- r/s+w/s 類似於交款人的總數
- 平均隊列長度(avgqu-sz)類似於單位時間里平均排隊人的個數
- 平均服務時間(svctm)類似於收銀員的收款速度
- 平均等待時間(await)類似於平均每人的等待時間
- 平均I/O數據(avgrq-sz)類似於平均每人所買的東西多少
- I/O 操作率 (%util)類似於收款台前有人排隊的時間比例。
- 我們可以根據這些數據分析出 I/O 請求的模式，以及 I/O 的速度和響應時間。
下面是別人寫的這個參數輸出的分析
# iostat -x 1 Linux 3.10.0-514.26.2.el7.x86_64 (v01-ops-es03) 2018年06月27日 _x86_64_ (2 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 15.10 0.00 5.72 18.54 0.00 60.64 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.24 0.40 0.15 0.15 2.64 2.65 35.08 0.00 1.55 2.94 0.20 0.69 0.02 sdb 0.00 0.10 0.06 0.05 0.54 0.69 22.27 0.00 1.68 3.08 0.07 0.42 0.00
上面的 iostat 輸出表明秒有 28.57 次設備 I/O 操作: 總IO(io)/s = r/s(讀) +w/s(寫) = 1.02+27.55 = 28.57 (次/秒) 其中寫操作占了主體 (w:r = 27:1)。
- 平均每次設備 I/O 操作只需要 5ms 就可以完成，但每個 I/O 請求卻需要等上 78ms，為什么? 因為發出的 I/O 請求太多 (每秒鍾約 29 個)，假設這些請求是同時發出的，那么平均等待時間可以這樣計算:
- 平均等待時間 = 單個 I/O 服務時間 * ( 1 + 2 + … + 請求總數-1) / 請求總數
- 應用到上面的例子: 平均等待時間 = 5ms * (1+2+…+28)/29 = 70ms，和 iostat 給出的78ms 的平均等待時間很接近。這反過來表明 I/O 是同時發起的。
- 每秒發出的 I/O 請求很多 (約 29 個)，平均隊列卻不長 (只有 2 個 左右)，這表明這 29 個請求的到來並不均勻，大部分時間 I/O 是空閑的。
- 一秒中有 14.29% 的時間 I/O 隊列中是有請求的，也就是說，85.71% 的時間里 I/O 系統無事可做，所有 29 個 I/O 請求都在142毫秒之內處理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8，表明每秒內的I/O請求總共需要等待2232.8ms。所以平均隊列長度應為 2232.8ms/1000ms = 2.23，而 iostat 給出的平均隊列長度 (avgqu-sz) 卻為 22.35，為什么?! 因為 iostat 中有 bug，avgqu-sz 值應為 2.23，而不是 22.35
二、Linux iowait過高問題的查找及解決
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的結果就是我們要查找的文件