用pt-stalk定位MySQL短暂的性能问题

背景】

MySQL出现短暂的3-30秒的性能问题，通常的监控工具较难抓到现场，很难准肯定位问题缘由。

对于这类需求，咱们平常的MySQL分析工具都有些不足的地方：

一、 性能监控工具，目前粒度是分钟级，没法反应秒级的性能波动；

二、 MySQL Performance_schema工具采集是3秒落地10000行记录，对于QPS大于3000以上的服务器采集会丢失数据；

Performance_schema数据一般用来分析语句级的性能问题，好比CPU高消耗，扫描行数等语句问题，对于系统内部mutex，lock，thread等资源竞争的问题没法定位。

三、 Table DML工具（5分钟粒度）

四、 Slow Log记录大于1秒的慢查询，反应的多是果，而不是因

五、 MySQL Guard工具实现是依赖报警系统触发，通常对于持续在1分钟以上的问题能够抓取到现场

前面扩展过一个功能，对高CPU的监控，粒度能够到10秒左右

 

pt-stalk工具能够解决更细粒度的故障现场采集，守护进程的方式试用了一下，能够帮助咱们解决一些问题。

 

【pt-stalk工具的使用】

尝试用pt-stalk工具作故障现场的快照采集

一、自定义脚本，定义CPU做为触发条件

function trg_plugin(){

a=$(sar 1 1 | grep -i "Average:"| awk '{print $8}');echo 100 - $a |bc

}

二、用pt-stalk开启守护进程，下面命令实现了用自定义的pt_cpu.sh脚本作为判断条件，当CPU的值（100-%idle）大于50，判断的间隔时间为1秒，连续3次知足条件时触发快照采集，触发后会sleep 60秒

pt-stalk --daemonize --dest=/tmp/log/pt-stalk --user= --password= --port= --function=/tmp/pt_cpu.sh --variable highcpu --cycles=3 --interval=1 --threshold 50 --sleep=60 --log=/var/log/pt-stalk.log

具体的参数可参考man pt-stalk。

 

【案例分析】

有台服务器出现短暂的线程和CPU告警的问题，如今天天在9点多都有CPU的告警，但持续时间较短，MySQL Guard工具很难采集到现场。

按照以前性能计数器反应的指标，猜想是因为binlog备份致使的IO上升，又致使了线程积压，但实际不是这个缘由，binlog备份时间重合只是巧合。

在这台服务器开启pt-stalk守护进程后，今天早上CPU告警时触发了采集

抓取的快照信息以下：

依据故障快照信息，再结合slow log和performance_schema语句明细，有足够的信息能够定位出问题缘由。

一、在9:01分CPU出现上升

二、pt-stalk采集的CPU信息记录了更细粒度，连续30秒的信息，其中连续30秒CPU sys占比都在80%以上，一般是并发线程较高，context switch太高致使的sys消耗

三、连续30秒的Threads_running确实比较高

四、进一步分析，容易找到问题缘由是因为天天9:00定时job运行，有一句高并发的慢查询SQL致使了线程积压

六、 慢查询SQL是因为缺失索引致使，补建索引后观察，CPU的问题解决了

 

 

【pt-stalk的性能】

正常状况下守护进程的性能开销并不大，建议能够在有须要排障时再定制开启。下面是它的处理逻辑