MYSQL 的CPU 使用率高,干時間長的DB們都會遇到,其實其餘的數據庫也都是有相似的問題,CPU一升高。大部分DBA 的首要工做就是要看是否是有大事務,大查詢,慢查詢等等。實際上咱們是否是有更好的快速定位的方法
mysql
下圖咱們能夠看到系統CPU一直在 90%, 到底什麼緣由形成MYSQL的CPU 利用率一直高怎麼分析。follow me.
sql
咱們經過pidstat 來查看當前MYSQL的線程中那個CPU的使用率比較高
數據庫
能夠經過上圖看到0 和 1 號CPU 核心的使用率比較其餘的核心要高,而且咱們也看到TID ,線程的數字,而後咱們拿到這些線程的ID 直接回到MYSQL 內部,咱們看看到底這兩個線程在作什麼。
微信
咱們能夠結合上面的查詢socket
1 咱們能夠肯定到底多核心CPU上到底那個核心的CPU的利用率比較高spa
2 經過查找到哪一個核心的CPU的使用率多少,定位到MYSQL 中的有問題的鏈接。.net
另外也能夠經過監控系統來查看CPU 消耗在哪裏,例如可使用PMM,查看CPU 的消耗點在哪裏,若是是用戶user的層面,那就能夠確認是用戶的某些線程消耗了CPU的資源。而後能夠經過上面的手段來定位當前到底那些線程在大量的使用CPU線程
這裏有一個插曲,曾經聽到若是遇到這樣的狀況,添加CPU 暫時緩解CPU LOAD 100 percent 的狀況,這裏作了一個test.
3d
將上面的有壓力的MYSQL 的CPU 添加一倍從4 croe 變爲 8核心,最終結果(至少在我這裏),CPU的LOAD 基本上沒有變化,在負載一樣的狀況。orm
另外同時能夠用下面的腳本,看一下瞬時的 QPS TPS 看看是否是系統已經超負荷運行。
mysqladmin -uroot -p'password' --socket=/data/mysql/mysql.sock extended-status -i1|awk 'BEGIN{local_switch=0;print "QPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- "}
$2 ~ /Queries$/ {q=$4-lq;lq=$4;}
$2 ~ /Com_commit$/ {c=$4-lc;lc=$4;}
$2 ~ /Com_rollback$/ {r=$4-lr;lr=$4;}
$2 ~ /Threads_connected$/ {tc=$4;}
$2 ~ /Threads_running$/ {tr=$4;
if(local_switch==0)
{local_switch=1; count=0}
else {
if(count>10)
{count=0;print "------------------------------------------------------- \nQPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- ";}
else{
count+=1;
printf "%-6d %-8d %-7d %-8d %-10d %d \n", q,c,r,c+r,tc,tr;
}
}
}'
同時能夠輔助查看當前的handler_read_rnd , handler_read_rnd_next 等參數,若是快速的增加,說明當前的查詢有全表掃描或者沒法有效利用索引的狀況。
剩下的工做可能就要和相關的一些慢查詢或者捕捉到的語句來進行相關的分析了。
本文分享自微信公衆號 - AustinDatabases(AustinDatabases)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。