linux服務器硬盤IO讀寫負載高來源定位 pt-ioprofile


首先 、用top命令查看  
 
1
2
3
4
5
top - 16:15:05 up 6 days,  6:25,  2 users,  load average: 1.45, 1.77, 2.14
  Tasks: 147 total,   1 running, 146 sleeping,   0 stopped,   0 zombie
  Cpu(s):  0.2% us,  0.2% sy,  0.0% ni, 86.9% id, 12.6% wa,  0.0% hi,  0.0% si
  Mem:   4037872k total,  4003648k used,    34224k free,     5512k buffers
  Swap:  7164948k total,   629192k used,  6535756k free,  3511184k cached
 
  查看12.6% wa (指CPU等待磁盤寫入完成的時間)
  IO等待所占用的CPU時間的百分比,高過30%時IO壓力高
  其次、 用iostat -x 1 10  (-x 選項將用於顯示和io相關的擴展數據; 1表示間隔;10表示時間)
  如果 iostat 沒有,要  yum install sysstat  
 
1
2
3
4
5
6
avg-cpu:  %user   %nice    %sys %iowait   %idle
  0.00       0.00     0.25    33.46    66.29
  Device:    rrqm/s  wrqm/s   r/s    w/s     rsec/s   wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
  sda          0.00    0.00      0.00   0.00    0.00    0.00         0.00     0.00     0.00           0.00    0.00    0.00   0.00
  sdb          0.00   1122  17.00  9.00  192.00 9216.00    96.00  4608.00   123.79   137.23 1033.43  13.17 100.10
  sdc          0.00    0.00     0.00   0.00     0.00     0.00      0.00     0.00     0.00             0.00    0.00      0.00   0.00
 
  查看%util 100.10 %idle 66.29
  %util: 在統計時間內所有處理IO時間,除以總共統計時間。例如,如果統計間隔1秒,該設備有0.8秒在處理IO,而0.2秒閑置,那么該設備的%util = 0.8/1 = 80%,所以該參數暗示了設備的繁忙程度。一般地,如果該參數是100%表示設備已經接近滿負荷運行了(當然如果是多磁盤,即使%util是100%,因為磁盤的並發能力,所以磁盤使用未必就到了瓶頸)。
  idle小於70% IO壓力就較大了,一般讀取速度有較多的wait.
  同時可以結合vmstat 查看查看b參數(等待資源的進程數)  
 
1
vmstat 1

 

IO負載高的來源定位

 

前言:

在一般運維工作中經常會遇到這么一個場景,服務器的IO負載很高(iostat中的util),但是無法快速的定位到IO負載的來源進程和來源文件導致無法進行相應的策略來解決問題。

這個現象在MySQL上更為常見,在5.6(performance_schema提供io instrument)之前,我們通常只能猜到是MySQL導致的高IO,但是沒法定位具體是哪個文件帶來的負載。

例如是ibdata的刷寫?還是冷門ibd的隨機讀取?

本文就將介紹一個比較簡單的定位IO高負載的流程。

 

工具准備:

iotop: http://guichaz.free.fr/iotop/

pt-ioprofile:http://www.percona.com/downloads/percona-toolkit/2.2.1/

 


 

Step1 : iostat 查看IO情況

 iostat -x 1 查看IO情況,從下圖可以看到dfa這個磁盤的IO負載較高,接下來我們就來定位具體的負載來源

 


 

 Step2: iotop定位負載來源進程

 iotop的本質是一個python腳本,從proc中獲取thread的IO信息,進行匯總。

從下圖可以看出大部分的IO來源都來自於mysqld進程。因此可以確定dfa的負載來源是數據庫

 

 


 

Step3 pt-ioprofile定位負載來源文件

 pt-ioprofile的原理是對某個pid附加一個strace進程進行IO分析。

以下是摘自官網的一段警示:

 However, it works by attaching strace to the process using ptrace(), which will make it run very slowly until strace detaches. In addition to freezing the server, there is also some risk of the process crashing or performing badly after strace detaches from it, or indeed of strace not detaching cleanly and leaving the process in a sleeping state. As a result, this should be considered an intrusive tool, and should not be used on production servers unless you are comfortable with that.

通過ps aux|grep mysqld 找到 mysqld進程對應的進程號,通過pt-ioprofile查看哪個文件的IO占用時間最多。

默認參數下該工具展示的是IO占用的時間。

 

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

 

從上圖可以看出IO負載的主要來源是sbtest (sysbench的IO bound OLTP測試)。

並且壓力主要集中在讀取上。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM