問題描述

問題分析

第一步：

使用linux的top命令追蹤，發(fā)現(xiàn)是mysql進(jìn)程占用了幾乎所有的cpu資源，得到mysql的進(jìn)程號。

第二步：

mysql為單進(jìn)程多線程的數(shù)據(jù)庫，因此使用top –H –p MYDQLPID的方式追蹤，發(fā)現(xiàn)mysql的多線程中7點(diǎn)30左右開始是有1-3線程占用cpu單核90%資源，到8點(diǎn)40左右，40+線程占用cpu單核90%資源，服務(wù)器只有48邏輯核心，服務(wù)器資源耗盡。

第三步：

在問題發(fā)生的時段去觀測比較困難，但是mysql也沒有類似oracle的ash機(jī)制，因此采用了一個笨一點(diǎn)的辦法采用mysql定時任務(wù)機(jī)制，每5秒采集一次mysql進(jìn)程信息。將performance_schema.threads中的數(shù)據(jù)插入到臨時表im_threads_monitor中， 分析在并發(fā)起來的時刻占用mysql的資源sql。

第四步：

問題最終指向了下面這條sql，在im_threads_monitor中占比90%以上

select id,created_at into v_archive_id,v_archive_created_at

from archive

where created_at >= v_created_date

and created_at <= DATE_ADD(v_created_date, INTERVAL 10 minute )

and xml like concat(‘%id=/’’,v_msg_unique_id,’/’%’)

該sql單次執(zhí)行在1s-2s，但是并發(fā)上來以后變成20s+，事件為send date(該事件名字可能存在誤導(dǎo)性，其真實(shí)含義代表收集數(shù)據(jù)和發(fā)送數(shù)據(jù))全表掃描180萬條數(shù)據(jù)，該表有時間分區(qū)，但是數(shù)據(jù)基本都是近期的分區(qū)，另外該sql沒有使用到索引。

第五步：

分析慢SQL頻繁被執(zhí)行的原因。

該sql是未讀消息提示業(yè)務(wù)。業(yè)務(wù)中存在bug導(dǎo)致產(chǎn)生了一些無效的未讀消息，這些消息不會因?yàn)楹筮叺奈醋x消息發(fā)送功能發(fā)送出去，所以產(chǎn)生堆積，當(dāng)產(chǎn)生無效未讀消息很多時，以上慢SQL在用戶登錄時被執(zhí)行，但是無效消息只會在超過30天以后才被清理掉，用戶反復(fù)登錄會被重復(fù)執(zhí)行。

第六步：

修改清理無效未讀消息的機(jī)制，縮短保存時間；對archive表的created_at字段建立索引。觀察cpu使用率明顯降低

第七步：

修改mysql的參數(shù)innodb_thread_concurrency，將其設(shè)置為40，此時mysql最多可以使用40個線程。因此即使mysql壓力過大也不會影響Nginx。

https://www.cndba.cn/hehdba/article/4211https://www.cndba.cn/hehdba/article/4211

https://www.cndba.cn/hehdba/article/4211

總結(jié)：

1、早oltp系統(tǒng)中索引的涉及非常重要，很多業(yè)務(wù)會因?yàn)?條索引的確實(shí)而導(dǎo)致數(shù)據(jù)庫整個崩潰，而在數(shù)據(jù)量小的時候索引的作用往往看不出來。本次的問題也是業(yè)務(wù)的異常導(dǎo)致的一個小表變大表，進(jìn)而影響了整個業(yè)務(wù)。

2、合理的設(shè)置innodb_thread_concurrency參數(shù)對mysql來說非常重要。https://www.cndba.cn/hehdba/article/4211

https://www.cndba.cn/hehdba/article/4211

版權(quán)聲明：本文為博主原創(chuàng)文章，未經(jīng)博主允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的mysql服务器端口cpu_mysql导致服务器cpu100%的问题一例的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。