巧用pt-ioprofile 工具

一、描述

     生産系統資料庫性能壓力比較大，cpu iowait 40%~50% ，資料庫系統登入難。需要查出來是什麼程序導緻的，最好是找到是什麼檔案引起的。

二、操作過程

1.因為是資料庫系統，很容易知道是mysqld引起的，使用glances系統工具。

2. pt-ioprofile的原理是對某個pid附加一個strace程序進行IO分析。通過ps aux|grep mysqld 找到 mysqld程序對應的程序号，通過pt-ioprofile檢視哪個檔案的IO占用時間最多，對于定位問題更有用的是通過IO的吞吐量來進行定位。使用參數 --cell=sizes，該參數将結果已 B/s 的方式展示出來：

# ps -ef|grep mysql

# pt-ioprofile --profile-pid=113106 --cell=sizes

Mon May 15 13:48:36 CST 2017

Tracing process ID 113106

     total                     pread       read               pwrite      write      fsync       open      close      lseek  ftruncate filename

2032296082          0               3424256          0             146          0              0            0             2028871680          0 /data/disk1/mysqllogs/relay-bin.002231

 486457344         482263040          0    4194304          0          0          0          0          0          0 /data/disk1/mysqldata/dcs@002dpartition/t_warn_info_history#P#p201705.ibd

 148111360         540672          0  147570688          0          0          0          0          0          0 /data/disk1/mysqldata/ibdata1

  19590656            0          0   19590656          0          0          0          0          0          0 /data/disk1/mysqldata/ib_logfile0

   6725632          0     162765          0          0          0          0          0    6562867          0 /data/mysqllogs/relay-bin.002231

   3429905          0          0          0    3429905          0          0          0          0          0 /data/disk1/mysqllogs/mysql-bin.000431

     35824          0          0          0      17912          0          0          0      17912          0 /data/disk1/mysqldata/innodb_status.113106

     32768      32768          0          0          0          0          0          0          0          0 /data/disk1/mysqldata/mysql/slave_master_info.ibd

       561          0         66          0          0          0          0          0        495          0 /data/mysqllogs/relay-bin.index

       448          0          0          0        448          0          0          0          0          0 /data/mysqllogs/relay-bin.002232

       314          0          0          0        314          0          0          0          0          0 /data/disk1/mysqllogs/error.log

         0          0          0          0          0          0          0          0          0          0 /data/mysqllogs/relay-bin.~rec~

         0          0          0          0          0          0          0          0          0          0 /data/mysqllogs/relay-bin.index_crash_safe

         0          0          0          0          0          0          0          0          0          0 /data/mysqllogs/

         0          0          0          0          0          0          0          0          0          0 /data/disk1/mysqllogs/relay-bin.index

# 

通過上面很容易發現是因為複制引起的性能問題，進一步再去檢視複制狀态即可，結合業務分析為什麼會出現周期性的插入波峰。

最終處理隻是修改了資料庫的個别參數，主要是記憶體相關的參數，明天需要繼續觀察。本來計劃要更新一下系統配置，如果通過分析修改資料庫、系統系統參數解決了此問題。那麼才能展現DBA的價值~

本文轉自 roidba 51CTO部落格，原文連結：http://blog.51cto.com/roidba/1925986，如需轉載請自行聯系原作者