在一般运维工作中经常会遇到这么一个场景, 服务器的 IO 负载很高 (iostat 中的 util), 但是无法快速的定位到 IO 负载的来源进程和来源文件导致无法进行相应的策略来解决问题.
这个现象在 MySQL 上更为常见, 在 5.6(performance_schema 提供 io instrument) 之前, 我们通常只能猜到是 MySQL 导致的高 IO, 但是没法定位具体是哪个文件带来的负载.
例如是 ibdata 的刷写? 还是冷门 ibd 的随机读取?
工具准备:
- iotop: http://guichaz.free.fr/iotop/
- pt-ioprofile: http://www.percona.com/downloads/percona-toolkit/2.2.1/
step1 : iostat 查看 IO 情况
iostat -x -d 1 查看 IO 情况, 从下图可以看到 dfa 这个磁盘的 IO 负载较高, 接下来我们就来定位具体的负载来源
Step2: iotop 定位负载来源进程
iotop 的本质是一个 python 脚本, 从 proc 中获取 thread 的 IO 信息, 进行汇总
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 的方式展示出来
来源: http://www.bubuko.com/infodetail-2584693.html