mysql负载高怎么解决,mysql cpu 高 各种原因

mysql数据库服务器CPU负载超过200%，mysqld进程导致的，如何解决？

可以先使用 uptime 命令查看 CPU 平均负载

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：主机域名、虚拟主机、营销软件、网站建设、雁山网站维护、网站推广。

那个 2 users 表示用户连接数，指的是总连接数。

那个 load average 就是系统平均负载，1 分钟、5 分钟、15 分钟系统负载的平均值。

指的是一段时间内 CPU 正在处理以及等待 CPU 处理的进程数之和的统计信息，也就是 CPU 使用队列的长度的统计信息。这个数字越小越好。

然后再用 vmstat 命令看下 CPU 是否饱和

这里面的 r 就是等待 CPU 的进程数，可以用来判定 CPU 是否饱和，当 r 值高于 CPU 数时，就意味着饱和了。

最右边那个 us，sy，id，wa，st 表示所有 CPU 的使用百分比。它们分别是 user time，system time，idle，wait I/O 和 steal time 的缩写。将 us 和 sy 的百分比加和，可以确定 CPU 是否处于忙碌状态。

如果是多核的机器还可以使用 mpstat 命令查看是否均衡

与 CPU 相关的命令还有 pidstat

这个命令展示了 CPU 消耗在了哪些进程上面，消耗过大的进程需要格外关注下。

基本上你使用上述几个命令 就可以初步了解 CPU 出现了何种问题

有了猜测的方向之后 你就可以进一步深入去排查了

MySQL CPU占用过高怎么办

MySQL CPU占用过高原因主要有以下几种

CPU过时（比较旧的CPU）

RAM资源不足（RAM记忆体）

解决办法如下：

①临时解决方案

首先是ctrl+alt+delete快捷键打开工作管理员

然后找到下方图一中的mysqld.exe

右击移至详细资料

再来右击设定优先顺序

按照下方图二的步骤

根据占用情况调整成低于标准或者低

这个方法只能临时解决

②实际解决方法是更换CPU

总结：根据正常的mysql使用，即使大量数据往来也不会造成CPU占用过高，目前推论应该是CPU比较过时的原因，治标不治本的临时解决方案。

备注：如采取方案②你需要备份你的资料，因为更换CPU会有很大的机会需要重新安装你的作业系统。

mysql中cpu负载很高，是什么原因

mysql中cpu负载很高，是什么原因

1、确定高负载的类型

htop，dstat命令看负载高是CPU还是IO

看具体是哪个用户哪个进程占用了相关系统资源，当前CPU、内存谁在使用

2、监控具体的sql语句，是insert

update

还是

delete导致高负载

抓取mysql包分析，一般抓3306端口的数据

看出最繁忙的sql语句了

3、检查mysql日志

分析mysql慢日志，查看哪些sql语句最耗时

检查mysql配置参数是否有问题，引起大量的IO或者高CPU操作

innodb_flush_log_at_trx_commit

、innodb_buffer_pool_size

、key_buffer_size

等重要参数

4、检查硬件问题

Mysql占用CPU过高如何优化

CPU占用过高诊断思路

mpstat -P ALL 1，查看cpu使用情况，主要消耗在sys即os系统调用上

perf top，cpu主要消耗在_spin_lock

生成perf report查看详细情况

CPU主要消耗在mutex争用上，说明有锁热点。

采用pt-pmp跟踪mysqld执行情况，热点主要集中在mem_heap_alloc和mem_heap_free上。

Pstack提供更详细的API调用栈

Innodb在读取数据记录时的API路径为

row_search_for_mysql --》row_vers_build_for_consistent_read --》mem_heap_create_block_func --》mem_area_alloc --》malloc --》  _L_unlock_10151 --》__lll_unlock_wait_private

row_vers_build_for_consistent_read会陷入一个死循环，跳出条件是该条记录不需要快照读或者已经从undo中找出对应的快照版本，每次循环都会调用mem_heap_alloc/free。

而该表的记录更改很频繁，导致其undo history list比较长，搜索快照版本的代价更大，就会频繁的申请和释放堆内存。

Linux原生的内存库函数为ptmalloc，malloc/free调用过多时很容易产生锁热点。

当多条 SQL 并发执行时，会最终触发os层面的spinlock，导致上述情形。

解决方案

将mysqld的内存库函数替换成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高并发调用。

修改my.cnf，添加如下参数并重启

[mysqld_safe]malloc-lib=tcmalloc

上周五早上7点执行的操作，到现在超过72小时，期间该实例没有再出现cpu长期飙高的情形。

以下是修改前后cpu使用率对比

mysql 负载高可用 哪个方案最好

mysql负责高可用，可以参考如下几种方案：

1.基于共享存储的方案SAN

方

案介绍：SAN(Storage Area

Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统

并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动MySQL。共享存储的架构如下:

优点:

1.可以避免存储外的其它组件引起的数据丢失。

2.部署简单，切换逻辑简单，对应用透明。

3.保证主备数据的强一致。

限制或缺点:

1.共享存储是单点，若共享存储挂了，则会丢失数据。

2.价格比价昂贵。

2.基于磁盘复制的方案 DRBD

方

案介绍：DRBD(Distributed Replicated Block

Device)是一种磁盘复制技术，可以获得和SAN类似的效果。DBRD是一个以linux内核模块方式实现的块级别同步复制技术。它通过网卡将主服务

器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD与SAN类似，也是有一个热备机器，开始提供服务时会使用和故障机器相

同的数据，只不过DRBD的数据是复制存储，不是共享存储。DRBD的架构图如下：

优点：

1.切换对应用透明

2.保证主备数据的强一致。

限制或缺点：

1.影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。

2.一般配置两节点同步，可扩展性比较差

3.备库不能提供读服务，资源浪费

3.基于主从复制(单点写)方案

前面讨论的两种方案分别依赖于底层的共享存储和磁盘复制技术，来解决MYSQL服务器单点和磁盘单点的问题。而实际生产环境中，高可用更多的是依赖

MySQL本身的复制，通过复制为Master制作一个或多个热副本，在Master故障时，将服务切换到热副本。下面的几种方案都是基于主从复制的方

案，方案由简单到复杂，功能也越来越强大，实施难度由易到难，各位可以根据实际情况选择合适的方案。