如何分析用pt-stalk定位MySQL短暫的性能問題

本篇文章為大家展示了如何分析用pt-stalk定位MySQL短暫的性能問題，內(nèi)容簡明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

10年積累的成都做網(wǎng)站、成都網(wǎng)站建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有謝通門免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

【背景】

MySQL出現(xiàn)短暫的3-30秒的性能問題，一般的監(jiān)控工具較難抓到現(xiàn)場(chǎng)，很難準(zhǔn)確定位問題原因。

對(duì)于這類需求，我們?nèi)粘５腗ySQL分析工具都有些不足的地方：

1、性能監(jiān)控工具，目前粒度是分鐘級(jí)，無法反應(yīng)秒級(jí)的性能波動(dòng)；

2、 MySQL Performance_schema工具采集是3秒落地10000行記錄，對(duì)于QPS大于3000以上的服務(wù)器采集會(huì)丟失數(shù)據(jù)；

Performance_schema數(shù)據(jù)通常用來分析語句級(jí)的性能問題，比如CPU高消耗，掃描行數(shù)等語句問題，對(duì)于系統(tǒng)內(nèi)部mutex，lock，thread等資源競(jìng)爭(zhēng)的問題無法定位。

3、 Table DML工具（5分鐘粒度）

4、 Slow Log記錄大于1秒的慢查詢，反應(yīng)的可能是果，而不是因

5、 MySQL Guard工具實(shí)現(xiàn)是依賴報(bào)警系統(tǒng)觸發(fā)，一般對(duì)于持續(xù)在1分鐘以上的問題可以抓取到現(xiàn)場(chǎng)

前面擴(kuò)展過一個(gè)功能，對(duì)高CPU的監(jiān)控，粒度可以到10秒左右

pt-stalk工具可以解決更細(xì)粒度的故障現(xiàn)場(chǎng)采集，守護(hù)進(jìn)程的方式試用了一下，可以幫助我們解決一些問題。

【pt-stalk工具的使用】

嘗試用pt-stalk工具做故障現(xiàn)場(chǎng)的快照采集

1、自定義腳本，定義CPU作為觸發(fā)條件

function trg_plugin(){

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

}

2、用pt-stalk開啟守護(hù)進(jìn)程，下面命令實(shí)現(xiàn)了用自定義的pt_cpu.sh腳本做為判斷條件，當(dāng)CPU的值（100-%idle）大于50，判斷的間隔時(shí)間為1秒，連續(xù)3次滿足條件時(shí)觸發(fā)快照采集，觸發(fā)后會(huì)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

具體的參數(shù)可參考man pt-stalk。

【案例分析】

有臺(tái)服務(wù)器出現(xiàn)短暫的線程和CPU告警的問題，現(xiàn)在每天在9點(diǎn)多都有CPU的告警，但持續(xù)時(shí)間較短，MySQL Guard工具很難采集到現(xiàn)場(chǎng)。

按照之前性能計(jì)數(shù)器反應(yīng)的指標(biāo)，猜測(cè)是由于binlog備份導(dǎo)致的IO上升，又導(dǎo)致了線程積壓，但實(shí)際不是這個(gè)原因，binlog備份時(shí)間重合只是巧合。

在這臺(tái)服務(wù)器開啟pt-stalk守護(hù)進(jìn)程后，今天早上CPU告警時(shí)觸發(fā)了采集

如何分析用pt-stalk定位MySQL短暫的性能問題