一、描述

生產系統數據庫性能壓力比較大，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 [email protected]/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” 博客，請務必保留此出處http://roidba.blog.51cto.com/12318731/1925986

巧用pt-ioprofile 工具