緊急處理:
執行平穩的資料庫,如果遇到cpu狂飆,到80%左右,那一定是開發寫的爛sql導致的,dba首先要保證的是,資料庫別跑掛了,所以我們要把那些執行慢的sql殺死並記錄到檔案裡,以便後面的排查。
pt-
kill
--match-info "^(select|select)"--busy-time 3--victim all --interval 1--kill --print --daemonize > /root/kill.txt
pt工具安裝
pt-kill詳解
這條命令是只把select耗時3秒以上的sql全部殺死,並列印出來
模擬測試:
也可以通過show processlist;命令詳細排查:
1.通過top命令查詢伺服器cup占用情況
我們看到cup佔用率已經達到199.7%(伺服器是雙核)
2.執行 mysql -u root -p 進入mysql,輸入show full processlist; 檢視正在連線mysql的執行緒
show processlist詳解
我們看到這個sql是導致mysql資料庫飆公升的原因
3.殺死這些占用資源的爛sql
kill 504;
kill 509;
通過mysql慢日誌分析:
1、檢視mysql日誌記錄是否開啟:show variables like 『slow_query_log』;
沒開啟的話先開啟日誌記錄: set global slow_query_log = on;
set global long_query_time =3;
3、檢視日誌存放位置:show variables like 『slow_query_log_file』;
4、檢視日誌: cat /data/mysql/***/long.log
# time: 170104 10:41:04
# user@host: root[root] @ [127.0.0.1] id: 785264
# query_time: 2.082531 lock_time: 0.000132 rows_sent: 0 rows_examined: 437963
settimestamp
=1483497664
;select id,update_time,update_end_time,ctime from
`sg_point_log`
where pid =
105and
date
(ctime)
= curdate(
)and
(update_time !=
0or update_end_time !=0)
order
by id desc
limit1;
# time: 170104 10:42:06
# user@host: root[root] @ [127.0.0.1] id: 785461
# query_time: 2.037191 lock_time: 0.000162 rows_sent: 0 rows_examined: 438013
settimestamp
=1483497726
;select id,update_time,update_end_time,ctime from
`sg_point_log`
where pid =
203and
date
(ctime)
= curdate(
)and
(update_time !=
0or update_end_time !=0)
order
by id desc
limit1;
# time: 170104 10:42:10
# user@host: root[root] @ [127.0.0.1] id: 785549
# query_time: 2.003415 lock_time: 0.000071 rows_sent: 0 rows_examined: 438016
settimestamp
=1483497730
;select id,update_time,update_end_time,ctime from
`sg_point_log`
where pid =
281and
date
(ctime)
= curdate(
)and
(update_time !=
0or update_end_time !=0)
order
by id desc
limit1;
# time: 170104 10:42:14
# user@host: root[root] @ [127.0.0.1] id: 785264
# query_time: 2.152803 lock_time: 0.000127 rows_sent: 0 rows_examined: 438018
settimestamp
=1483497734
;select id,update_time,update_end_time,ctime from
`sg_point_log`
where pid =
8and
date
(ctime)
= curdate(
)and
(update_time !=
0or update_end_time !=0)
order
by id desc
limit1;
# time: 170104 10:42:16
# user@host: root[root] @ [127.0.0.1] id: 785264
# query_time: 2.040670 lock_time: 0.000077 rows_sent: 0 rows_examined: 438021
settimestamp
=1483497736
;select id,upload_img_time,ctime from
`sg_point_log`
where pid =
7and
date
(ctime)
= curdate(
)and upload_img_time !=
0order
by id desc
limit1;
# time: 170104 10:42:18
# user@host: root[root] @ [127.0.0.1] id: 785264
# query_time: 2.139948 lock_time: 0.000124 rows_sent: 0 rows_examined: 438025
settimestamp
=1483497738
;select id,update_time,update_end_time,ctime from
`sg_point_log`
where pid =
7and
date
(ctime)
= curdate(
)and
(update_time !=
0or update_end_time !=0)
order
by id desc
limit
1;
可以看出罪魁禍首就是這個sq CPU飆公升問題排查
服務異常報警,cpu 100 1.執行top命令 查詢程序id為 17239 2.檢視程序內的哪些執行緒cpu 高 top hp 17239 3.通過jstack生成dump資訊 jstack 17239 jstack date y m d h m s txt 查詢執行緒dump檔案裡面執行緒為17...
如何使用Windbg 查Cpu飆公升問題
2 開啟windbg 設定 file symbol search path 位址如下 c symbols srv c mylocalsymbols srv c mysymbol 3 開啟windbg 將程序轉存的程序檔案 拉進windbg 4 在windbg介面 輸入載入命令 load c wind...
伺服器CPU飆公升問題解決過程
問題出現前的提要 1 專案需求 將大量資料通過kafka訊息佇列 到另外的專案中 2 專案打完版本後,3點開始cpu開始飆公升 報錯資訊 解決問題方式 1 重啟伺服器 關閉大量資料的 暫時解決問題。2 開始分析問題 1 檢查 檢視有沒有死鎖或者有沒有占用大量cpu的 檢查結果沒有發現 問題,排除問題...