• 企业400电话
  • 微网小程序
  • AI电话机器人
  • 电商代运营
  • 全 部 栏 目

    企业400电话 网络优化推广 AI电话机器人 呼叫中心 网站建设 商标✡知产 微网小程序 电商运营 彩铃•短信 增值拓展业务
    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 

        从上面的结果中,可以看到,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)

         从这个结果来看,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)

        操作如上,这样我们修改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 

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

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

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

    以上就是mysql CPU高负载问题排查的详细内容,更多关于MySQL cpu高负载的资料请关注脚本之家其它相关文章!

    您可能感兴趣的文章:
    • 详解Mysql双机热备和负载均衡的实现步骤
    • 利用MySQL系统数据库做性能负载诊断的方法
    • MySQL如何实现负载均衡功能
    • 如何使用nginx充当mysql的负载均衡器
    • 在OneProxy的基础上实行MySQL读写分离与负载均衡
    • 基于mysql+mycat搭建稳定高可用集群负载均衡主备复制读写分离操作
    • python实现mysql的读写分离及负载均衡
    • Keepalived+HAProxy实现MySQL高可用负载均衡的配置
    • 分析MySQL中索引引引发的CPU负载飙升的问题
    • 快速增加MYSQL数据库连接数负载能力的方法分享
    • 具有负载均衡功能的MySQL服务器集群部署及实现
    上一篇:MySQL数据库备份过程的注意事项
    下一篇:详解MySQL8.0 密码过期策略
  • 相关文章
  • 

    © 2016-2020 巨人网络通讯 版权所有

    《增值电信业务经营许可证》 苏ICP备15040257号-8

    mysql CPU高负载问题排查 mysql,CPU,高负载,高,负载,