mysql CPU高负载问题排查

2024-12-13 15:58:27

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高负载的资料请关注我们其它相关文章！

Keepalived+HAProxy实现MySQL高可用负载均衡的配置

Keepalived 由于在生产环境使用了mysqlcluster,需要实现高可用负载均衡,这里提供了keepalived+haproxy来实现. keepalived主要功能是实现真实机器的故障隔离及负载均衡器间的失败切换.可在第3,4,5层交换.它通过VRRPv2(Virtual Router Redundancy Protocol) stack实现的. Layer3:Keepalived会定期向服务器群中的服务器.发送一个ICMP的数据包(既我们平时用的Ping程序),如果发现某台服务的
如何使用nginx充当mysql的负载均衡器

说明:nginx版本要求是1.9以上 ,编译nginx的时候需要加上 --with-stream 如: ./configure --prefix=/Data/apps/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_realip_module --with-http_image_filter_module --with-stream 注意 1.因为mysql默认使用了3306端口所以配置nginx t
分析MySQL中索引引引发的CPU负载飙升的问题

收到一个mysql服务器负载告警,上去一看,load average都飙到280多了,用top一看,CPU跑到了336%,不过IO和内存的负载并不高,根据经验,应该又是一起索引引起的惨案了. 看下processlist以及slow query情况,发现有一个SQL经常出现,执行计划中的扫描记录数看着还可以,单次执行耗时为0.07s,还不算太大.乍一看,可能不是它引发的,但出现频率实在太高,而且执行计划看起来也不够完美: mysql> explain SELECT count(1) FROM a
快速增加MYSQL数据库连接数负载能力的方法分享

第一先限制Innodb的并发处理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看机器压力,如果非常大,先改成16让机器的压力下来,然后慢慢增达,适应自已的业务.处理方法: set global innodb_thread_concurrency=16; 方法一: (window系统中可直接修改my.ini文件) 进入MYSQL安装目录打开MYSQL配置文件 my.ini 或 my.cnf查找 max_connections=100 修改为 max_
python实现mysql的读写分离及负载均衡

Oracle数据库有其公司开发的配套rac来实现负载均衡,目前已知的最大节点数能到128个,但是其带来的维护成本无疑是很高的,并且rac的稳定性也并不是特别理想,尤其是节点很多的时候. 但是,相对mysql来说,rac的实用性要比mysql的配套集群软件mysql-cluster要高很多.因为从网上了解到情况来看,很少公司在使用mysql-cluster,大多数企业都会选择第三方代理软件,例如MySQL Proxy.Mycat.haproxy等,但是这会引起另外一个问题:单点故障(包括mysql
利用MySQL系统数据库做性能负载诊断的方法

某大师曾说过,像了解自己的老婆一样了解自己管理的数据库,个人认为包含了两个方面的了解: 1,在稳定性层面来说,更多的是关注高可用.读写分离.负载均衡,灾备管理等等high level层面的措施(就好比要保证生活的稳定性) 2,在实例级别的来说,需要关注内存.IO.网络,热点表,热点索引,top sql,死锁,阻塞,历史上执行异常的SQL(好比生活品质细节)MySQL的performance_data库和sys库提供了非常丰富的系统日志数据,可以帮助我们更好地了解非常细节的,这里简单地列举出来了
详解Mysql双机热备和负载均衡的实现步骤

MySQL数据库没有增量备份的机制,但它提供了一种主从备份的机制,就是把主数据库的所有的数据同时写到备份数据库中.实现MySQL数据库的热备份. 下面是具体的主从热备份的步骤: 假设主服务器A(master).从服务器为B(slave) A:192.168.0.104 B:192.168.0.169 1.主服务器授权授权副服务器可以连接主服务器并可以进行更新.这是在主服务器上进行的,创建一个username和password供副服务器访问时使用.也可以使用主服务器默认的帐号和密码. 2.数据复
基于mysql+mycat搭建稳定高可用集群负载均衡主备复制读写分离操作

数据库性能优化普遍采用集群方式,oracle集群软硬件投入昂贵,今天花了一天时间搭建基于mysql的集群环境. 主要思路简单说,实现mysql主备复制-->利用mycat实现负载均衡. 比较了常用的读写分离方式,推荐mycat,社区活跃,性能稳定. 测试环境 MYSQL版本:Server version: 5.5.53,到官网可以下载WINDWOS安装包. 注意:确保mysql版本为5.5以后,以前版本主备同步配置方式不同. linux实现思路类似,修改my.cnf即可. A主mysql.19
具有负载均衡功能的MySQL服务器集群部署及实现

在实际生产环境中,部署和实现具有一定负载均衡功能的 MySQL服务器集群,对于提高用户数据库应用系统的性能.速度和稳定性具有明显的作用.本文简要介绍了在 FreeBSD 7.0-Release系统上部署实现MySQL服务器集群的方案,并对可能出现的问题提供了相应的解决方法.1. 引言MySQL是一个高速度.高性能.多线程.开放源代码,建立在客户/服务器(Client /Server)结构上的关系型数据库管理系统(RDBMS).它始于1979年,最初是Michael Widenius为瑞典TcX公
在OneProxy的基础上实行MySQL读写分离与负载均衡

简介 Part1:写在最前 OneProxy平民软件完全自主开发的分布式数据访问层,帮助用户在MySQL/PostgreSQL集群上快速搭建支持分库分表的分布式数据库中间件,也是一款具有SQL白名单(防SQL注入)及IP白名单功能的SQL防火墙软件.采用与MySQL Proxy一致的反向协议输出模式,对应用非常简单和透明易用,让用户畏惧的数据库故障切换(Failover).读写分离(Read/Write Split).分库分表(Horizontal Partitioning)等复杂方案变得极其简
MySQL如何实现负载均衡功能

前言 MySQL是一个高速度.高性能.多线程.开放源代码,建立在客户/服务器(Client/Server)结构上的关系型数据库管理系(RDBMS).它始于1979年,最初是MichaelWidenius为瑞典TcX公司创建的UNIREG数据库系统,当时的UNIREG没有SQL(StructuredQueryLanguage结构化查询语言)接口,限制了它的应用. 1996年5月,Widenius开发出了MySQL的最初版本,开始在Internet上公开发行.MySQL的开发人员从一开始就一直关注它

mysql CPU高负载问题排查

相关推荐

随机推荐