I/O性能分析-對問題的分析不能只看表象
0x01 緣由
最近，生產環境下出現了一些事故，系統宕機。隨之大家開始重視運維，最近發佈版本程序後，系統集成部對一進程I/O進行了報警，說程序I/O佔用99%，如下圖：
IO那列長期處於99%！
0x02 I/O分析中關注的一些參數
磁盤利用率(disk utilization)
磁盤隊列長度(disk queue length)
磁頭/邏輯卷的讀/寫速率(read/write rates per spindle/logical volume)
原始I/O(raw I/O)：主要用於數據庫應用
交換隊列的長度(swap queue length)
緩存命中率(buffer cache hit ratio)
網絡文件系統和無盤工作站速率(NFS and diskless rates(server))
0x02 I/O資源成爲系統性能的瓶頸的徵兆
過高的磁盤利用率(high disk utilization)
太長的磁盤等待隊列(large disk queue length)
等待磁盤I/O的時間所佔的百分率太高(large percentage of time waiting for disk I/O)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
過低的緩存命中率(low buffer cache hit ratio(not sufficient in itself))
太長的運行進程隊列，但CPU卻空閒(large run queue with idle CPU)
0x03佔用I/O資源的大戶
換頁(paging):paging不僅會引起內存問題，還可能引起磁盤問題；
open,creat,and stat system calls：系統調用會引起大量的磁盤I/O；
multiuser I/O and random I/O
relational database
core dumps
0x04 常用分析工具
iotop:
作用：iotop命令是一個用來監視磁盤I/O使用狀況的top類工具。
man iotop:
iotop顯示在採樣期間由每個進程/線程讀取和寫入的I / O帶寬的列。 它還顯示線程/進程交換時和在等待I/ O時花費的時間百分比。對於每個進程，顯示其I /O優先級（類/級別）。 此外，在採樣週期內讀取和寫入的總I/ O帶寬顯示在接口頂部。
選項：
-o：只顯示有io操作的進程。
-b：批量顯示，無交互，主要用作記錄到文件。
-n NUM：顯示NUM次，主要用於非交互式模式。
-d SEC：間隔SEC秒顯示一次。
-p PID：監控的進程pid。
-u USER：監控的進程用戶。
實例:
再次理解發現，此參數只表明I/O花費時間百分比。
iostat:
作用：iostat命令被用於監視系統輸入輸出設備和CPU的使用情況。它的特點是彙報磁盤活動統計情況，同時也會彙報出CPU使用情況。同vmstat一樣，iostat也有一個弱點，就是它不能對某個進程進行深入分析，僅對系統的整體情況進行分析。
選項：
每列的意義：
Device 監測設備名稱
rrqm/s 每秒需要讀取需求的數量
wrqm/s 每秒需要寫入需求的數量
r/s 每秒實際讀取需求的數量
w/s 每秒實際寫入需求的數量
rsec/s 每秒讀取區段的數量
wsec/s 每秒寫入區段的數量
rkB/s 每秒實際讀取的大小，單位爲KB
wkB/s 每秒實際寫入的大小，單位爲KB
avgrq-sz 需求的平均大小區段
avgqu-sz 需求的平均隊列長度
await 等待I/O平均的時間（milliseconds）
svctm I/O需求完成的平均時間
%util 被I/O需求消耗的CPU百分比
pidstat:
作用：pidstat主要用於監控全部或指定進程佔用系統資源的情況，如CPU，內存、設備IO、任務切換、線程等。pidstat首次運行時顯示自系統啓動開始的各項統計信息，之後運行pidstat將顯示自上次運行該命令以後的統計信息。用戶可以通過指定統計的次數和時間來獲得所需的統計信息。
實例：
http://www.cnblogs.com/ggjucheng/archive/2013/01/13/2858874.html
工具很多，不再列舉。
1、如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。
2、svctm 一般要小於 await (因爲同時等待的請求的等待時間被重複計算了)，svctm 的大小一般和磁盤性能有關，CPU/內存的負荷也會對其有影響，請求過多也會間接導致 svctm 的增加。
await 的大小一般取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時間；如果 await 遠大於 svctm，說明 I/O 隊列太長，應用得到的響應時間變慢，如果響應時間超過了用戶可以容許的範圍，這時可以考慮更換更快的磁盤，調整內核 elevator 算法，優化應用，或者升級 CPU。
每列的意義：
Device 監測設備名稱
rrqm/s 每秒需要讀取需求的數量
wrqm/s 每秒需要寫入需求的數量
r/s 每秒實際讀取需求的數量
w/s 每秒實際寫入需求的數量
rsec/s 每秒讀取區段的數量
wsec/s 每秒寫入區段的數量
rkB/s 每秒實際讀取的大小，單位爲KB
wkB/s 每秒實際寫入的大小，單位爲KB
avgrq-sz 需求的平均大小區段
avgqu-sz 需求的平均隊列長度
await 等待I/O平均的時間（milliseconds）
svctm I/O需求完成的平均時間
%util 被I/O需求消耗的CPU百分比
pidstat:
作用：pidstat主要用於監控全部或指定進程佔用系統資源的情況，如CPU，內存、設備IO、任務切換、線程等。pidstat首次運行時顯示自系統啓動開始的各項統計信息，之後運行pidstat將顯示自上次運行該命令以後的統計信息。用戶可以通過指定統計的次數和時間來獲得所需的統計信息。
實例：
http://www.cnblogs.com/ggjucheng/archive/2013/01/13/2858874.html
工具很多，不再列舉。
0x05瓶頸的判斷依據
iostat:1、如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。
2、svctm 一般要小於 await (因爲同時等待的請求的等待時間被重複計算了)，svctm 的大小一般和磁盤性能有關，CPU/內存的負荷也會對其有影響，請求過多也會間接導致 svctm 的增加。
await 的大小一般取決於服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。如果 svctm 比較接近 await，說明 I/O 幾乎沒有等待時間；如果 await 遠大於 svctm，說明 I/O 隊列太長，應用得到的響應時間變慢，如果響應時間超過了用戶可以容許的範圍，這時可以考慮更換更快的磁盤，調整內核 elevator 算法，優化應用，或者升級 CPU。