用pt-stalk定位MySQL短暫的效能問題
【背景】
MySQL出現短暫的3-30秒的效能問題,一般的監控工具較難抓到現場,很難準確定位問題原因。
對於這類需求,我們日常的MySQL分析工具都有些不足的地方:
1、 效能監控工具,目前粒度是分鐘級,無法反應秒級的效能波動;
2、 MySQL Performance_schema工具採集是3秒落地10000行記錄,對於QPS大於3000以上的伺服器採集會丟失資料;
Performance_schema資料通常用來分析語句級的效能問題,比如CPU高消耗,掃描行數等語句問題,對於系統內部mutex,lock,thread等資源競爭的問題無法定位。
3、 Table DML工具(5分鐘粒度)
4、 Slow Log記錄大於1秒的慢查詢,反應的可能是果,而不是因
5、 MySQL Guard工具實現是依賴報警系統觸發,一般對於持續在1分鐘以上的問題可以抓取到現場
前面擴充套件過一個功能,對高CPU的監控,粒度可以到10秒左右
pt-stalk工具可以解決更細粒度的故障現場採集,守護程序的方式試用了一下,可以幫助我們解決一些問題。
【pt-stalk工具的使用】
嘗試用pt-stalk工具做故障現場的快照採集
1、自定義指令碼,定義CPU作為觸發條件
function trg_plugin(){
a=$(sar 1 1 | grep -i "Average:"| awk '{print $8}');echo 100 - $a |bc
}
2、用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語句明細,有足夠的資訊可以定位出問題原因。
1、在9:01分CPU出現上升
2、pt-stalk採集的CPU資訊記錄了更細粒度,連續30秒的資訊,其中連續30秒CPU sys佔比都在80%以上,通常是併發執行緒較高,context switch過高導致的sys消耗
3、連續30秒的Threads_running確實比較高
4、進一步分析,容易找到問題原因是由於每天9:00定時job執行,有一句高併發的慢查詢SQL導致了執行緒積壓
6、 慢查詢SQL是由於缺失索引導致,補建索引後再觀察
【pt-stalk的效能】
正常情況下守護程序的效能開銷並不大,建議可以在有需要排障時再定製開啟。下面是它的處理邏輯