用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的性能】

正常狀況下守護進程的性能開銷並不大，建議能夠在有須要排障時再定製開啓。下面是它的處理邏輯