≡
  • 网络编程
  • 数据库
  • CMS技巧
  • 软件编程
  • PHP笔记
  • JavaScript
  • MySQL
位置：首页 > 数据库 > MySQL

MySQL CPU高负载问题排查示例

人气：282 时间：2021-08-18

这篇文章主要为大家详细介绍了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%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

MySQL CPU高负载问题排查

    从上面的结果中，可以看到，8核的cpu只有一个核上面的负载是100%，其他的都是0%，而按照CPU使用率排序的结果也是mysqld的进程占用CPU比较多。

   之前从来没有遇到过这个问题，当时第一反应是在想是不是有些业务层面的问题，比如说一些慢查询一直在占用CPU的资源，于是登陆到MySQL上使用show processlist查看了当前的进程，发现除了有少许update操作之外，没有其他的SQL语句在执行。于是我又查看了一眼慢日志，发现慢日志中的SQL语句执行时间都很短，大多数都是由于未使用索引导致的，但是扫描的记录数都很少，只有几百行，这样看起来业务层面的问题是不存在的。

  排除了业务层面的问题，现在看看数据库层面的问题，查看了一眼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)

MySQL CPU高负载问题排查

     从这个结果来看，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的大小，看看这个问题还会不会发生：

代码如下：


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)

MySQL CPU高负载问题排查

    操作如上，这样我们修改buffer pool的值为1G，我们设置的值是1073741824，而实际的值变成了1074790400，这个原因在上面已经说过了，就是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

MySQL CPU高负载问题排查

   可以发现，CPU的使用率已经下去了，为了防止偶然现象，我又重新把buffer pool的大小改成了最初的5M的值，发现之前的问题又复现了，也就是说，设置大的buffer pool确实是一种解决方法。

    到这里，问题是解决了，但是这个问题背后引发的一些东西却值得思考，小的buffer pool为什么会导致其中一个CPU的使用率是100%？

   这里，我能想到的一个原因是5M的buffer pool太小了，会导致业务SQL在读取数据的时候和磁盘频繁的交互，而磁盘的速度比较慢，所以会提高IO负载，导致CPU的负载过高，至于为什么只有一个CPU的负载比较高，其他的近乎为0，这个问题可能还需要查一查，如果有知道的朋友，还请不吝赐教。

以上就是mysql CPU高负载问题排查的详细内容，更多关于MySQL cpu高负载的资料请关注四海网其它相关文章！

本文来自：http://www.q1010.com/177/19618-0.html

注：关于MySQL CPU高负载问题排查示例的内容就先介绍到这里，更多相关文章的可以留意四海网的其他信息。

关键词：高负载

您可能感兴趣的文章

  • php 大型高并发高负载网站的系统架构功能实例
上一篇：解决MySQL 组合AND和OR带来的问题示例
下一篇：IDEA使用mybatis-generator及配上MySQL8.0.3版本遇到的bug的简单示例
热门文章
  • mysql 修改character_set_server为utf-8的简单示例
  • 解决MySQL丢失文件localhost.localdomain.pid、mysql.sock的示例
  • MySQL 数据类型binary和varbinary的简单示例
  • MySQL:reading initial communication packet问题解决方法
  • MySql 表类型MYISAM、InnoDB区别
  • bash: mysql: command not found 的解决方法
  • MYSQL默认用户名ROOT修改方法
  • MySQL 常用命令菜鸟教程
  • MySQL 使用命令行新建用户并授予权限
  • MySql 数据库物理文件存放位置查看示例
  • 最新文章
    • MySQL查看死锁与解除死锁的简单示例
    • MySQL 慢查询的功能实例
    • MySQL查看死锁与去除死锁的简单示例
    • MySQL找出未提交事务的SQL的简单示例
    • MySQL锁阻塞的的简单示例
    • MySQL中的binary类型使用操作的示例
    • SQL优化教程之in与range查询的简单示例
    • MySQL 的 21 个规范、优化最佳实践！
    • MySQL 字符类型大小写敏感的简单示例
    • 解决mybatis-plus分页传入参数后sql where条件没有limit分页信息的问题

四海网收集整理一些常用的php代码,JS代码,数据库mysql等技术文章。