负载定位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测试）。

    并且压力重要中集在读取上。

 

 

 

 

 

 

 

 

文章结束给大家分享下程序员的一些笑话语录： 女人篇
　　有的女人就是Windows虽然很优秀，但是安全隐患太大。
　　有的女人就是MFC她条件很好，然而不是谁都能玩的起。
　　有的女人就是C#长的很漂亮，但是家务活不行。
　　有的女人就是C++,她会默默的为你做很多的事情。
　　有的女人就是汇编虽然很麻烦，但是有的时候还得求它。
　　有的女人就是SQL，她会为你的发展带来莫大的帮助。