欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

MySQL占用CPU過高,排查原因及解決方案

 更新時(shí)間:2022年12月22日 10:38:06   作者:Beucejiang  
這篇文章主要介紹了MySQL占用CPU過高,排查原因及解決方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教

一、mysql中的wait_timeout坑

mysql> show variables like '%timeout%';

首先你要明白:

  • wait_timeout — 指的是mysql在關(guān)閉一個(gè)非交互的連接之前所要等待的秒數(shù),其取值范圍為1-2147483(Windows),1-31536000(linux),默認(rèn)值28800。
  • nteractive_time — 指的是mysql在關(guān)閉一個(gè)交互的連接之前所要等待的秒數(shù)(交互連接如mysql gui tool中的連接),其取值范圍隨wait_timeout變動(dòng),默認(rèn)值28800。

所謂的交互式連接,即在mysql_real_connect()函數(shù)中使用了CLIENT_INTERACTIVE選項(xiàng)。說得直白一點(diǎn),通過mysql客戶端連接數(shù)據(jù)庫是交互式連接,通過jdbc連接數(shù)據(jù)庫是非交互式連接。

MySQL 的默認(rèn)設(shè)置下,當(dāng)一個(gè)連接的空閑時(shí)間超過8小時(shí)后,一到高峰期肯定會(huì)造成,會(huì)有太多的TCP連接沒關(guān)閉,數(shù)據(jù)庫連接數(shù)肯定是不夠。

從而會(huì)產(chǎn)生CPU占用過高,服務(wù)器告警等問題。因EPG的一個(gè)訪問一次對(duì)數(shù)據(jù)庫操作量不大,查詢完數(shù)據(jù)就完成ok了,wait_timeout 設(shè)置在120s內(nèi)就很完美了。

1、第一種修改方式 需重啟MySQL(6.5為例)

1.1、修改參數(shù)配置文件   

vi /etc/my.cnf

[mysqld]
wait_timeout?? ?= 90
interactive_timeout?? ?=? 90
#增加以上兩列即可,因?yàn)楣俜轿臋n要求修改此參數(shù)必須同時(shí)修改interactive_timeout

1.2、重啟數(shù)據(jù)庫 

service mysqld restart? 

或者

/etc/init.d/mysql restart

1.3、查看數(shù)據(jù)庫參數(shù)是否修改成功 

連接MySQL 然后查看 

show variables like ‘wait_timeout';

2、第二種修改方式 不需重啟MySQL(數(shù)據(jù)庫重啟就失效)

mysql>?show?variables?like?'%timeout';

    +-------------------------+-------+
    |?Variable_name???????????|?Value?|
    +-------------------------+-------+
    |?connect_timeout?????????|?10????|
    |?delayed_insert_timeout??|?300???|
    |?interactive_timeout?????|?200???|
    |?net_read_timeout????????|?30????|
    |?net_write_timeout???????|?60????|
    |?slave_net_timeout???????|?3600??|
    |?table_lock_wait_timeout?|?50????|
    |?wait_timeout????????????|?200???|
    +-------------------------+-------+

  mysql>?set?global?interactive_timeout=100;

    Query?OK,?0?rows?affected?(0.00?sec)

退出后重新登錄mysql

如果修改interactive_timeout的話wait_timeout也會(huì)跟著變,而只修改wait_timeout是不生效的。

二、排查有沒有地方占用SQL資源過多

show databases;

3、use  數(shù)據(jù)庫名;         #切換到常用數(shù)據(jù)庫

4、show full processlist;    #顯示哪些線程正在運(yùn)行

或者:

-- select * from information_schema.PROCESSLIST?where info is not null;

說明各列的含義和用途

  • id列: 一個(gè)標(biāo)識(shí),你要kill 一個(gè)語句的時(shí)候很有用。
  • user列:  顯示當(dāng)前用戶,如果不是root,這個(gè)命令就只顯示你權(quán)限范圍內(nèi)的sql語句。
  • host列: 顯示這個(gè)語句是從哪個(gè)ip 的哪個(gè)端口上發(fā)出的??捎脕碜粉櫝鰡栴}語句的用戶。
  • db列: 顯示這個(gè)進(jìn)程目前連接的是哪個(gè)數(shù)據(jù)庫。
  • command列: 顯示當(dāng)前連接的執(zhí)行的命令,一般就是休眠(sleep),查詢(query),連接(connect)。

 通常代表資源未釋放,如果是通過連接池,sleep狀態(tài)應(yīng)該恒定在一定數(shù)量范圍內(nèi)

 實(shí)戰(zhàn)范例:因前端數(shù)據(jù)輸出時(shí)(特別是輸出到用戶終端)未及時(shí)關(guān)閉數(shù)據(jù)庫連接,導(dǎo)致因網(wǎng)絡(luò)連接速度產(chǎn)生大量sleep連接,在網(wǎng)速出現(xiàn)異常時(shí),數(shù)據(jù)庫too many connections掛死。

簡單解讀,數(shù)據(jù)查詢和執(zhí)行通常只需要不到0.01秒,而網(wǎng)絡(luò)輸出通常需要1秒左右甚至更長,原本數(shù)據(jù)連接在0.01秒即可釋放,但是因?yàn)榍岸顺绦蛭磮?zhí)行close操作,直接輸出結(jié)果,那么在結(jié)果未展現(xiàn)在用戶桌面前,該數(shù)據(jù)庫連接一直維持在sleep狀態(tài)!

  • time列: 此這個(gè)狀態(tài)持續(xù)的時(shí)間,單位是秒。
  • state列: 顯示使用當(dāng)前連接的sql語句的狀態(tài),很重要的列,后續(xù)會(huì)有所有的狀態(tài)的描述,請注意,state只是語句執(zhí)行中的某一個(gè)狀態(tài),一個(gè)sql語句,已查詢?yōu)槔赡苄枰?jīng)過copying to tmp table,Sorting result,Sending data等狀態(tài)才可以完成。
  • info列: 顯示這個(gè)sql語句,因?yàn)殚L度有限,所以長的sql語句就顯示不全,但是一個(gè)判斷問題語句的重要依據(jù)。

其中state的狀態(tài)十分關(guān)鍵

下表列出state主要狀態(tài)和描述:

狀態(tài)描述
Checking table正在檢查數(shù)據(jù)表(這是自動(dòng)的)。
Closing tables正在將表中修改的數(shù)據(jù)刷新到磁盤中,同時(shí)正在關(guān)閉已經(jīng)用完的表。這是一個(gè)很快的操作,如果不是這樣的話,就應(yīng)該確認(rèn)磁盤空間是否已經(jīng)滿了或者磁盤是否正處于重負(fù)中。
Connect Out復(fù)制從服務(wù)器正在連接主服務(wù)器。
Copying to tmp table on disk由于臨時(shí)結(jié)果集大于tmp_table_size,正在將臨時(shí)表從內(nèi)存存儲(chǔ)轉(zhuǎn)為磁盤存儲(chǔ)以此節(jié)省內(nèi)存。
Creating tmp table正在創(chuàng)建臨時(shí)表以存放部分查詢結(jié)果。
deleting from main table服務(wù)器正在執(zhí)行多表刪除中的第一部分,剛刪除第一個(gè)表。
deleting from reference tables服務(wù)器正在執(zhí)行多表刪除中的第二部分,正在刪除其他表的記錄。
Flushing tables正在執(zhí)行FLUSH TABLES,等待其他線程關(guān)閉數(shù)據(jù)表。
Killed發(fā)送了一個(gè)kill請求給某線程,那么這個(gè)線程將會(huì)檢查kill標(biāo)志位,同時(shí)會(huì)放棄下一個(gè)kill請求。MySQL會(huì)在每次的主循環(huán)中檢查kill標(biāo)志位,不過有些情況下該線程可能會(huì)過一小段才能死掉。如果該線程程被其他線程鎖住了,那么kill請求會(huì)在鎖釋放時(shí)馬上生效。
Locked被其他查詢鎖住了。
Sending data正在處理SELECT查詢的記錄,同時(shí)正在把結(jié)果發(fā)送給客戶端。
Sorting for group正在為GROUP BY做排序。
Sorting for order正在為ORDER BY做排序。
Opening tables這個(gè)過程應(yīng)該會(huì)很快,除非受到其他因素的干擾。例如,在執(zhí)ALTER TABLE或LOCK TABLE語句行完以前,數(shù)據(jù)表無法被其他線程打開。正嘗試打開一個(gè)表。
Removing duplicates正在執(zhí)行一個(gè)SELECT DISTINCT方式的查詢,但是MySQL無法在前一個(gè)階段優(yōu)化掉那些重復(fù)的記錄。因此,MySQL需要再次去掉重復(fù)的記錄,然后再把結(jié)果發(fā)送給客戶端。
Reopen table獲得了對(duì)一個(gè)表的鎖,但是必須在表結(jié)構(gòu)修改之后才能獲得這個(gè)鎖。已經(jīng)釋放鎖,關(guān)閉數(shù)據(jù)表,正嘗試重新打開數(shù)據(jù)表。
Repair by sorting修復(fù)指令正在排序以創(chuàng)建索引。
Repair with keycache修復(fù)指令正在利用索引緩存一個(gè)一個(gè)地創(chuàng)建新索引。它會(huì)比Repair by sorting慢些。
Searching rows for update正在講符合條件的記錄找出來以備更新。它必須在UPDATE要修改相關(guān)的記錄之前就完成了。
Sleeping正在等待客戶端發(fā)送新請求.
System lock正在等待取得一個(gè)外部的系統(tǒng)鎖。如果當(dāng)前沒有運(yùn)行多個(gè)mysqld服務(wù)器同時(shí)請求同一個(gè)表,那么可以通過增加--skip-external-locking參數(shù)來禁止外部系統(tǒng)鎖。
Upgrading lockINSERT DELAYED正在嘗試取得一個(gè)鎖表以插入新記錄。
Updating正在搜索匹配的記錄,并且修改它們。
User Lock正在等待GET_LOCK()。
Waiting for tables該線程得到通知,數(shù)據(jù)表結(jié)構(gòu)已經(jīng)被修改了,需要重新打開數(shù)據(jù)表以取得新的結(jié)構(gòu)。然后,為了能的重新打開數(shù)據(jù)表,必須等到所有其他線程關(guān)閉這個(gè)表。以下幾種情況下會(huì)產(chǎn)生這個(gè)通知:FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。
waiting for handler insertINSERT DELAYED已經(jīng)處理完了所有待處理的插入操作,正在等待新的請求。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。

相關(guān)文章

最新評(píng)論