iotop: http://guichaz.free.fr/iotop/
pt-ioprofile: http://www.percona.com/downloads/percona-toolkit/2.2.1/
1、查看磁盤使用率 df -lh
2、安裝iostat 安裝命令: yum install sysstat
3、iostat -d -k 2 查看IO情況：
哪個磁盤的IO負載較高，接下來我們就來定位具體的負載來源
%util: 一秒中有百分之多少的時間用于 I/O 操作，或者說一秒中有多少時間 I/O 隊列是非空的。即 delta(use)/s/1000 (因為use的單位為毫秒)
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。
4、安裝iotop 命令：
安裝命令：yum install iotop iotop 查看哪個線程耗IO比較高、按 o 只顯示有磁盤 IO 活動的進程。
5、pt-ioprofile定位負載來源文件
pt-ioprofile --profile-pid=1236 --cell=sizes
pt-ioprofile的原理是對某個pid附加一個strace進程進行IO分析。
6、對于定位問題更有用的是通過IO的吞吐量來進行定位。使用參數 --cell=sizes，該參數將結果已 B/s 的方式展示出來
pt-ioprofile --profile-pid=1236 --cell=sizes
從上圖可以看出IO負載的主要來源是jetty。
并且壓力主要集中在讀取上。
前段時間，一個Mysql數據庫服務器磁盤IO寫非常高，經過排查，發現是mysql線程導致的，磁盤讀寫情況，如下圖所示
從上圖可以看到磁盤IO已經達到6.77M/S，mysql的版本是5.6，這個版本還沒有performance_schema.threads視圖的THREAD_OS_ID字段，沒辦法將操作系統的thread_id和mysql數據庫線程id進行關聯，不能精確定位是mysql那個線程產生的磁盤IO寫操作。
于是登錄mysql數據庫，臨時開始Mysql數據庫的general_log，查看日志記錄，也沒有發現什么特殊操作
這就很詭異了，到底是什么原因呢，只能祭出終極武器perf了，看看此時mysql數據庫什么函數操作占用資源最多。
[root@mysql ~]# ps -ef|grep -i mysqld
mysql 11650 1 0 8月29 ? 00:00:00 /bin/sh /data/mysql-8.0.21/bin/mysqld_safe --defaults-file=/data/mysql/mysql8/conf/3308/my.cnf
mysql 12694 11650 2 8月29 ? 00:59:29 /data/mysql-8.0.21/bin/mysqld --defaults-file=/data/mysql/mysql8/conf/3308/my.cnf --basedir=/data/mysql-8.0.21 --datadir=/data/mysql/mysql8/data/3308 --plugin-dir=/data/mysql-8.0.21/lib/plugin --log-error=/data/mysql/mysql8/log/3308/error.log --open-files-limit=65535 --pid-file=/data/mysql/mysql8/run/3308/mysql.pid --socket=/data/mysql/mysql8/run/3308/mysql.sock --port=3308
root 49777 49737 0 15:58 pts/0 00:00:00 grep --color=auto -i mysqld
[root@mysql ~]#
[root@mysql ~]#
[root@mysql ~]# perf top -p 12694
觀察結果如下圖所示
從圖中可以看到，buf_calc_page_new_checksum 函數操作占用的資源最多。
那么buf_calc_page_new_checksum 這個函數到底是做什么的呢？
在mysql刷盤時，會調用這個函數，這個函數的作用是checksum，并寫入頁中。，其調用順序如下所示
buf_flush_page-->buf_flush_write_block_low-->buf_flush_init_for_writing-->buf_calc_page_new_checksum
從上面可以看出，是Mysql數據庫在做刷臟頁操作，導致磁盤的IO寫特別高，這也是為什么在general_log看不出什么特殊操作的原因。