mysql CPU高負載問題排查
MySQL導致的CPU高負載問題
今天下午發現了一個MySQL導致的向上伺服器負載高的問題，事情的背景如下：
在某個新伺服器上，新建了一個MySQL的例項，該伺服器上面只有MySQL這一個程序，但是CPU的負載卻居高不下，使用top命令查詢的結果如下：
[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%st Cpu2 : 0.0%us,100.0%id,0.0%st Cpu3 : 0.3%us,0.0%st Cpu4 : 0.3%us,0.0%st Cpu5 : 0.0%us,0.0%st Cpu6 :100.0%us,0.0%id,0.0%st Cpu7 : 0.0%us,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
從上面的結果中，可以看到，8核的cpu只有一個核上面的負載是100%，其他的都是0%，而按照CPU使用率排序的結果也是mysqld的程序佔用CPU比較多。
之前從來沒有遇到過這個問題，當時第一反應是在想是不是有些業務層面的問題，比如說一些慢查詢一直在佔用CPU的資源，於是登陸到MySQL上使用show processlist查看了當前的程序，發現除了有少許update操作之外，沒有其他的SQL語句在執行。於是我又查看了一眼慢日誌，發現慢日誌中的SQL語句執行時間都很短，大多數都是由於未使用索引導致的，但是掃描的記錄數都很少，只有幾百行，這樣看起來業務層面的問題是不存在的。
排除了業務層面的問題，現在看看資料庫層面的問題，查看了一眼buffer pool，可以看到這個值是：
[email protected]:(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)
從這個結果來看，buffer pool的大小隻有5M大小，肯定是有問題的，一般情況下，線上環境的buffer pool都是1G往上，於是我查看了my.cnf配置檔案，在配置檔案中發現這個例項在啟動的時候，innodb_buffer_pool_size的設定是0M，是的，沒有看錯，是0M。這裡不得不提另外一個引數，我們可以看到innodb_buffer_pool_size的大小和innodb_buffer_pool_chunk_size的大小一樣，這個chunk的概念是記憶體塊，也就是說每次申請buffer pool的時候，是以"記憶體塊"為單位申請的，一個buffer pool當中包含多個記憶體塊，所以buffer pool size的大小需要是chunk size的整數倍。
由於innodb_buffer_pool_chunk_size本身的值為5M，當我們設定它為0M時，它會自動的將其大小設定為5M的倍數，所以我們的innodb_buffer_pool_size值是5M。
既然buffer pool的值比較小，那麼我將它改成1G的大小，看看這個問題還會不會發生：
[email protected]:(none) 17:20:41>>set global innodb_buffer_pool_size=1073741824; Query OK,0 rows affected,1 warning (0.00 sec) [email protected]:(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，我們設定的值是1073741824，而實際的值變成了1074790400，這個原因在上面已經說過了，就是chunk size的值影響的。
此時使用top命令觀察CPU使用情況：
[dba_mysql@dba-mysql ~]$ top top - 22:19:09 up 104 days,5:26,load average: 0.45,0.84,0.86 Tasks: 218 total,0.3%sy,99.3%id,0.0%st Cpu2 : 1.0%us,99.0%id,0.0%st Cpu3 : 1.0%us,0.0%st Cpu5 : 0.3%us,0.0%st Cpu6 : 0.0%us,0.0%st Cpu7 : 0.7%us,8008140k used,8310364k 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
可以發現，CPU的使用率已經下去了，為了防止偶然現象，我又重新把buffer pool的大小改成了最初的5M的值，發現之前的問題又復現了，也就是說，設定大的buffer pool確實是一種解決方法。
到這裡，問題是解決了，但是這個問題背後引發的一些東西卻值得思考，小的buffer pool為什麼會導致其中一個CPU的使用率是100%？
這裡，我能想到的一個原因是5M的buffer pool太小了，會導致業務SQL在讀取資料的時候和磁碟頻繁的互動，而磁碟的速度比較慢，所以會提高IO負載，導致CPU的負載過高，至於為什麼只有一個CPU的負載比較高，其他的近乎為0，這個問題可能還需要查一查，如果有知道的朋友，還請不吝賜教。
以上就是mysql CPU高負載問題排查的詳細內容，更多關於MySQL cpu高負載的資料請關注我們其它相關文章！