高清不卡一区二区在线,亚洲欧美中文日韩在线,中文国产亚洲喷潮

主頁 > 知識庫 > mysql CPU高負載問題排查

mysql CPU高負載問題排查

MySQL導(dǎo)致的CPU高負載問題

今天下午發(fā)現(xiàn)了一個MySQL導(dǎo)致的向上服務(wù)器負載高的問題，事情的背景如下：

在某個新服務(wù)器上，新建了一個MySQL的實例，該服務(wù)器上面只有MySQL這一個進程，但是CPU的負載卻居高不下，使用top命令查詢的結(jié)果如下：

[dba_mysql@dba-mysql ~]$ top 
top - 17:12:44 up 104 days, 20 min, 2 users, load average: 1.06, 1.02, 1.00
Tasks: 218 total,  1 running, 217 sleeping,  0 stopped,  0 zombie
Cpu0 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16318504k total, 7863412k used, 8455092k free,  322048k buffers
Swap: 5242876k total,    0k used, 5242876k free, 6226588k cached

  PID USER   PR NI VIRT RES SHR S %CPU %MEM  TIME+ COMMAND                                     
 75373 mysql   20  0 845m 699m 29m S 100.0 4.4 112256:10 mysqld                                     
 43285 root   20  0 174m 40m 19m S 0.7 0.3 750:40.75 consul                                      
116553 root   20  0 518m 13m 4200 S 0.3 0.1  0:05.78 falcon-agent                                   
116596 nobody  20  0 143m 6216 2784 S 0.3 0.0  0:00.81 python                                      
124304 dba_mysq 20  0 15144 1420 1000 R 0.3 0.0  0:02.09 top                                       
   1 root   20  0 21452 1560 1248 S 0.0 0.0  0:02.43 init

從上面的結(jié)果中，可以看到，8核的cpu只有一個核上面的負載是100%，其他的都是0%，而按照CPU使用率排序的結(jié)果也是mysqld的進程占用CPU比較多。

之前從來沒有遇到過這個問題，當(dāng)時第一反應(yīng)是在想是不是有些業(yè)務(wù)層面的問題，比如說一些慢查詢一直在占用CPU的資源，于是登陸到MySQL上使用show processlist查看了當(dāng)前的進程，發(fā)現(xiàn)除了有少許update操作之外，沒有其他的SQL語句在執(zhí)行。于是我又查看了一眼慢日志，發(fā)現(xiàn)慢日志中的SQL語句執(zhí)行時間都很短，大多數(shù)都是由于未使用索引導(dǎo)致的，但是掃描的記錄數(shù)都很少，只有幾百行，這樣看起來業(yè)務(wù)層面的問題是不存在的。

排除了業(yè)務(wù)層面的問題，現(xiàn)在看看數(shù)據(jù)庫層面的問題，查看了一眼buffer pool，可以看到這個值是：

mysql--dba_admin@127.0.0.1:(none) 17:20:35>>show variables like '%pool%';
+-------------------------------------+----------------+
| Variable_name            | Value     |
+-------------------------------------+----------------+
| innodb_buffer_pool_chunk_size    | 5242880    |
| innodb_buffer_pool_dump_at_shutdown | ON       |
| innodb_buffer_pool_dump_now     | OFF      |
| innodb_buffer_pool_dump_pct     | 25       |
| innodb_buffer_pool_filename     | ib_buffer_pool |
| innodb_buffer_pool_instances    | 1       |
| innodb_buffer_pool_load_abort    | OFF      |
| innodb_buffer_pool_load_at_startup | ON       |
| innodb_buffer_pool_load_now     | OFF      |
| innodb_buffer_pool_size       | 5242880    |
| thread_pool_high_prio_mode     | transactions  |
| thread_pool_high_prio_tickets    | 4294967295   |
| thread_pool_idle_timeout      | 60       |
| thread_pool_max_threads       | 100000     |
| thread_pool_oversubscribe      | 3       |
| thread_pool_size          | 8       |
| thread_pool_stall_limit       | 500      |
+-------------------------------------+----------------+
17 rows in set (0.01 sec)

從這個結(jié)果來看，buffer pool的大小只有5M大小，肯定是有問題的，一般情況下，線上環(huán)境的buffer pool都是1G往上，于是我查看了my.cnf配置文件，在配置文件中發(fā)現(xiàn)這個實例在啟動的時候，innodb_buffer_pool_size的設(shè)置是0M，是的，沒有看錯，是0M。這里不得不提另外一個參數(shù)，我們可以看到innodb_buffer_pool_size的大小和innodb_buffer_pool_chunk_size的大小一樣，這個chunk的概念是內(nèi)存塊，也就是說每次申請buffer pool的時候，是以"內(nèi)存塊"為單位申請的，一個buffer pool當(dāng)中包含多個內(nèi)存塊，所以buffer pool size的大小需要是chunk size的整數(shù)倍。

由于innodb_buffer_pool_chunk_size本身的值為5M，當(dāng)我們設(shè)置它為0M時，它會自動的將其大小設(shè)置為5M的倍數(shù)，所以我們的innodb_buffer_pool_size值是5M。

既然buffer pool的值比較小，那么我將它改成1G的大小，看看這個問題還會不會發(fā)生：

mysql--dba_admin@127.0.0.1:(none) 17:20:41>>set global innodb_buffer_pool_size=1073741824;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql--dba_admin@127.0.0.1:(none) 17:23:34>>show variables like '%pool%';         
+-------------------------------------+----------------+
| Variable_name            | Value     |
+-------------------------------------+----------------+
| innodb_buffer_pool_chunk_size    | 5242880    |
| innodb_buffer_pool_dump_at_shutdown | ON       |
| innodb_buffer_pool_dump_now     | OFF      |
| innodb_buffer_pool_dump_pct     | 25       |
| innodb_buffer_pool_filename     | ib_buffer_pool |
| innodb_buffer_pool_instances    | 1       |
| innodb_buffer_pool_load_abort    | OFF      |
| innodb_buffer_pool_load_at_startup | ON       |
| innodb_buffer_pool_load_now     | OFF      |
| innodb_buffer_pool_size       | 1074790400   |
| thread_pool_high_prio_mode     | transactions  |
| thread_pool_high_prio_tickets    | 4294967295   |
| thread_pool_idle_timeout      | 60       |
| thread_pool_max_threads       | 100000     |
| thread_pool_oversubscribe      | 3       |
| thread_pool_size          | 8       |
| thread_pool_stall_limit       | 500      |
+-------------------------------------+----------------+
17 rows in set (0.00 sec)

操作如上，這樣我們修改buffer pool的值為1G，我們設(shè)置的值是1073741824，而實際的值變成了1074790400，這個原因在上面已經(jīng)說過了，就是chunk size的值影響的。

此時使用top命令觀察CPU使用情況：

[dba_mysql@dba-mysql ~]$ top
top - 22:19:09 up 104 days, 5:26, 2 users, load average: 0.45, 0.84, 0.86
Tasks: 218 total,  1 running, 217 sleeping,  0 stopped,  0 zombie
Cpu0 : 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.7%us, 0.0%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16318504k total, 8008140k used, 8310364k free,  322048k buffers
Swap: 5242876k total,    0k used, 5242876k free, 6230600k cached

  PID USER   PR NI VIRT RES SHR S %CPU %MEM  TIME+ COMMAND                                     
 43285 root   20  0 174m 40m 19m S 1.0 0.3 753:07.38 consul                                      
116842 root   20  0 202m 17m 5160 S 1.0 0.1  0:21.30 python                                      
 75373 mysql   20  0 1966m 834m 29m S 0.7 5.2 112313:36 mysqld                                      
116553 root   20  0 670m 14m 4244 S 0.7 0.1  0:44.31 falcon-agent                                   
116584 root   20  0 331m 11m 3544 S 0.7 0.1  0:37.92 python2.6                                    
   1 root   20  0 21452 1560 1248 S 0.0 0.0  0:02.43 init

可以發(fā)現(xiàn)，CPU的使用率已經(jīng)下去了，為了防止偶然現(xiàn)象，我又重新把buffer pool的大小改成了最初的5M的值，發(fā)現(xiàn)之前的問題又復(fù)現(xiàn)了，也就是說，設(shè)置大的buffer pool確實是一種解決方法。

到這里，問題是解決了，但是這個問題背后引發(fā)的一些東西卻值得思考，小的buffer pool為什么會導(dǎo)致其中一個CPU的使用率是100%？

這里，我能想到的一個原因是5M的buffer pool太小了，會導(dǎo)致業(yè)務(wù)SQL在讀取數(shù)據(jù)的時候和磁盤頻繁的交互，而磁盤的速度比較慢，所以會提高IO負載，導(dǎo)致CPU的負載過高，至于為什么只有一個CPU的負載比較高，其他的近乎為0，這個問題可能還需要查一查，如果有知道的朋友，還請不吝賜教。

以上就是mysql CPU高負載問題排查的詳細內(nèi)容，更多關(guān)于MySQL cpu高負載的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章:

詳解Mysql雙機熱備和負載均衡的實現(xiàn)步驟
利用MySQL系統(tǒng)數(shù)據(jù)庫做性能負載診斷的方法
MySQL如何實現(xiàn)負載均衡功能
如何使用nginx充當(dāng)mysql的負載均衡器
在OneProxy的基礎(chǔ)上實行MySQL讀寫分離與負載均衡
基于mysql+mycat搭建穩(wěn)定高可用集群負載均衡主備復(fù)制讀寫分離操作
python實現(xiàn)mysql的讀寫分離及負載均衡
Keepalived+HAProxy實現(xiàn)MySQL高可用負載均衡的配置
分析MySQL中索引引引發(fā)的CPU負載飆升的問題
快速增加MYSQL數(shù)據(jù)庫連接數(shù)負載能力的方法分享
具有負載均衡功能的MySQL服務(wù)器集群部署及實現(xiàn)

標(biāo)簽：牡丹江惠州天津合肥呼和浩特沈陽阿里公主嶺

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《mysql CPU高負載問題排查》，本文關(guān)鍵詞 mysql,CPU,高負載,高,負載,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。

婷婷综合国产,91蜜桃婷婷狠狠久久综合9色 ,九九九九九精品,国产综合av

mysql CPU高負載問題排查