gps定位，定位iowait問題

先說：磁盤性能指標

先簡單描述下常用的磁盤性能指標，用來指導iowait問題分析定位

指標	描述
每秒 I/O 數	一次磁盤的連續讀或者連續寫稱為一次磁盤 I/O, 磁盤的 IOPS =每秒磁盤連續讀次數+每秒磁盤連續寫次數。傳輸小塊不連續數據時，參考該指標進行衡量
吞吐量	硬盤傳輸數據流的速度，傳輸數據速度=讀出數據+寫入數據。傳輸大塊不連續數據的數據，參考該指標進行衡量
平均 I/O 數據尺寸	為吞吐量除以 I/O 數目，該指標對揭示磁盤使用模式有重要意義。數據尺寸小于 32K，可認為磁盤使用模式以隨機存取為主；反之，可認為磁盤使用模式以順序存取為主。
磁盤活動時間百分比	即磁盤利用率。如果磁盤利用率超過 70%，應用進程將花費較長的時間等待 I/O完成，因為絕大多數進程在等待過程中將被阻塞或休眠。
服務時間	指磁盤讀或寫操作執行的時間，包括尋道，旋轉時延，和數據傳輸等時間。其大小一般和磁盤性能有關，CPU/mem的負荷也會對其有影響，請求過多也會間接導致服務時間的增加。如果該值持續超過 20ms，一般可考慮會對上層應用產生影響。
I/O 等待隊列長度	指待處理的 I/O 請求的數目，如果 I/O 請求壓力持續超出磁盤處理能力，該值將增加。需要注意的是，如果該磁盤為磁盤陣列虛擬的邏輯驅動器，需要再將該值除以組成這個邏輯驅動器的實際物理磁盤數目，以獲得平均單塊硬盤的I/O 等待隊列長度
等待時間	指磁盤讀或寫操作等待執行的時間，即在隊列中排隊的時間。如果 I/O 請求持續超出磁盤處理能力，意味著來不及處理的 I/O 請求不得不在隊列中等待較長時間。

再說：iowait？

是系統因為io導致的進程wait。系統在做io，導致沒有進程在干活，cpu在執行idle進程空轉。
所以iowait的產生要滿足兩個條件：

進程在等待io
等待io時沒有進程可運行

iowait實際測量的是cpu時間

iowait = (cpu idle time)/(all cpu time)

確認并跟蹤問題

gps定位？linux常用命令中有很多都具備該選項：top、sar、vmstat、mpstat、dstat等等

查找哪塊磁盤正在被寫入
iostat
命令詳解可以參考 linux命令—iostat
查找引起高I/O wait 對應的進程
iotop
命令詳解可參考 linux命令—iotop
查找哪個文件引起的I/Owait
lsof -p pid
命令詳解可參考 linux命令—lsof
lsof 命令可以展示一個進程打開的所有文件，或者打開一個文件的所有進程
pt-ioprofile定位負載來源文件(完全可以替代3)
pt-ioprofile的原理是對某個pid附加一個strace進程進行IO分析
默認參數下該工具展示的是IO占用的時間

[root@db25440 ~]# pt-ioprofile -p=25129
Thu May 17 18:48:35 CST 2018
Tracing process ID 25129total     pwrite      write      fsync  fdatasync       open filename11.709016   0.000000   2.634413   0.000000   9.074603   0.000000 /my/log/mysql-bin.0012009.093400   2.966219   0.000000   6.127181   0.000000   0.000000 /my/base/ib_logfile30.000419   0.000000   0.000000   0.000000   0.000000   0.000419 /dev/urandom
[root@db25440 ~]#

對于定位問題更有用的是通過IO的吞吐量來進行定位。使用參數 –cell=sizes，該參數將結果已 B/s 的方式展示出來

[root@db25440 ~]# pt-ioprofile -p=25129 -c=sizes
Thu May 17 18:49:25 CST 2018
Tracing process ID 25129total     pwrite      write      fsync  fdatasync       open filename40917504   40917504          0          0          0          0 /my/base/ib_logfile314300748          0   14300748          0          0          0 /my/log/mysql-bin.0012000          0          0          0          0          0 /dev/urandom
[root@db25440 ~]#

如果正常運行iowait并不高，突然間高了，可能是系統訪問量大了，最大的可能是磁盤滿了~
?
當I/O等待時間所占CPU時間的比重很高時，首先檢查機器是否正在大量使用交換空間，因為硬盤操作的速度遠遠低于RAM，所以當系統內存耗盡，開始使用交換空間的時候，系統的性能會受到嚴重影響。任何想要訪問硬盤的操作都要完成與硬盤的I/O交換。所以，故障排除的第一步是看內存是否耗盡，如果是，先解決這個問題。如果還有大量可用的RAM，需要明確哪個進程占用了大部分I/O操作。