解决Mysql占用cpu,内存高故障案例

      晚上大概7点钟左右，收到播放中心投诉，说视频播放很慢，加载很久不出来。一开始，哥以为是tomcat服务又挂了。所以到tomcat服务器上查看下catalina.out输出日志。却没发现任务错误信息。

分析：

       想了想，视频加载慢，会不会是数据库问题呢？果断上mysql数据库(从库)看下top如下：

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND   37258 mysql    20   0 17.2g  12g 5032 S 769.5 81.3   4383:29 mysqld

没想到cpu居然达到769%了！

     然后进入mysql的慢查询语句的目录下面，看下slow.log

select count(*) as col_0_0_ from card_received cardreceiv0_ where (cardreceiv0_.statusCode=‘1‘ or cardreceiv0_.statusCode=‘2‘) and (cardreceiv0_.ownerCardNum=‘8757003738566209‘ or cardreceiv0_.ownerPhoneNum=‘13724689717‘) and cardreceiv0_.readStatus=0G;

发现这条查询语句耗时5秒左右，但是slow.log里面全部是这条语句。所以我觉得很可疑。

再用explain分析下看

mysql> explain select count(*) as col_0_0_ from card_received cardreceiv0_ where (cardreceiv0_.statusCode=‘1‘ or cardreceiv0_.statusCode=‘2‘) and (cardreceiv0_.ownerCardNum=‘8757003738566209‘ or cardreceiv0_.ownerPhoneNum=‘13724689717‘) and cardreceiv0_.readStatus=0G;explain结果：************************** 1. row ***************************           id: 1           select_type: SIMPLE           table: cardreceiv0_           type: refpossible_keys: readStatus,ownerCardNum,statusCode,ownerPhoneNum           key: readStatus           key_len: 5           ref: const           rows: 2394190           Extra: Using where1 row in set (0.00 sec)ERROR: No query specified

居然扫描了：2394190行。。

   最后跟开发沟通后，因为这边表数据并不重要。故将一些旧数据情况了，表示已经清空了200万行！最后mysql的cpu终于降下来了。。

不过要彻底解决问题，仍需要优化语句，建立索引哪。不然数据多了，肯定还会出问题的。

好了，此次故障也仅仅给提供一些解决问题的思路。具体问题还是需要具体分析的。

本文出自 “梁恩宇-9527” 博客，请务必保留此出处http://liangey.blog.51cto.com/9097868/1659808

解决Mysql占用cpu,内存高故障案例

标签：mysql   cpu   linux   

小编还为您整理了以下内容，可能对您也有帮助：

MySQL占用虚拟内存非常高怎么办

本文章来介绍一下关于MySQL占用虚拟内存非常高的解决办法，有需要学习的朋友可参考本文章。

mysql狂吃内存，刚启动的内存只占700M，半天后1.5G，运行2天后就占3G内存了，包括FP，以前重启MYSQL就降下来了，这样我就设置计划任务每天早上自动重启mysql，但现在重启mysql也没用，竟然连同FP占用4.5G内存，而我服务器只有2G物理内存，造成网站运行超级慢。怎么办？？？？

服务器配置是win2003+PHP5+MYSQL5+ZEND3.3 ~~~~~my.ini

解决办法

解决mySQL占用内存超大问题

为了装mysql环境测试，装上后发现启动后mysql占用了很大的虚拟内存，达8百多兆。网上搜索了一下，得到高人指点my.ini。再也没见再详细的了..只好打开my.ini逐行的啃，虽然英文差了点，不过多少M还是看得明的^-^

更改后如下：

代码如下innodb_buffer_pool_size=576M 256M InnoDB引擎缓冲区占了大头，首要就是拿它开刀

query_cache_size=100M 16M 查询缓存

tmp_table_size=102M 64M 临时表大小

key_buffer_size=256m 32M

重启mysql服务后，虚拟内存降到200以下．

另外mysql安装目录下有几个文件：my-huge.ini 、my-large.ini、my-medium.ini...这几个是根据内存大小作的建议配置，新手在设置的时候也可以参考一下。

2G内存的MYSQL数据库服务器 my.ini优化 (my.ini)

2G内存,针对站少,优质型的设置,试验特：

代码如下table_cache=1024 物理内存越大,设置就越大.默认为2402,调到512-1024最佳

innodb_additional_mem_pool_size=8M 默认为2M

innodb_flush_log_at_trx_commit=0 等到innodb_log_buffer_size列队满后再统一储存,默认为1

innodb_log_buffer_size=4M 默认为1M

innodb_thread_concurrency=8 你的服务器CPU有几个就设置为几,默认为8

key_buffer_size=256M 默认为218 调到128最佳

tmp_table_size=64M 默认为16M 调到64-256最挂

read_buffer_size=4M 默认为64K

read_rnd_buffer_size=16M 默认为 ......

测试

2G内存,针对站多,抗压型的设置,最佳：

代码如下table_cache=1024 物理内存越大,设置就越大.默认为2402,调到512-1024最佳

innodb_additional_mem_pool_size=4M 默认为2M

innodb_flush_log_at_trx_commit=1

(设置为0就是等到innodb_log_buffer_size列队满后再统一储存,默认为1)

innodb_log_buffer_size=2M 默认为1M

innodb_thread_concurrency=8 你的服务器CPU有几个就设置为几,建议用默认一般为8

key_buffer_size=256M 默认为218 调到128最佳

tmp_table_size=64M 默认为16M 调到64-256最挂

read_buffer_size=4M 默认为64K

read_rnd_buffer_size=16M 默认为256K

sort_buffer_size=32M 默认为256K

max_connections=1024 默认为1210

thread_cache_size=120 默认为60

query_cache_size=64M

优化mysql数据库性能的十个参数:

(1)、max_connections

允许的同时客户的数量。增加该值增加 mysqld 要求的文件描述符的数量。这个数字应该增加，否则，你将经常看到 too many connections 错误。

(2)、record_buffer

每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描，你可能想要增加该值。

(3)、key_buffer_size

索引块是缓冲的并且被所有的线程共享。key_buffer_size是用于索引块的缓冲区大小，增加它可得到更好处理的索引(对所有读和多重写)，到你能负担得起那样多。如果你使它太大，系统将开始换页并且真的变慢了。

(4)、back_log

要求mysql能有的连接数量。当主要mysql线程在一个很短时间内得到非常多的连接请求，这就起作用，然后主线程花些时间(尽管很短)检查连接并且启动一个新线程。

back_log 值指出在mysql暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接，你需要增加它，换句话说，这值对到来的tcp/ip连接的侦听队列的大小。你的操作系统在这个队列大小上有它自己的。试图设定back_log高于你的操作系统的将是无效的。

当你观察你的主机进程列表，发现大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | null | connect | null | login | null 的待连接进程时，就要加大 back_log 的值了。

(5)、interactive_timeout

服务器在关闭它前在一个交互连接上等待行动的秒数。一个交互的客户被定义为对 mysql_real_connect()使用 client_interactive 选项的客户。

(6)、sort_buffer

每个需要进行排序的线程分配该大小的一个缓冲区。增加这值加速order by或group by操作。

(7)、table_cache

为所有线程打开表的数量。增加该值能增加mysqld要求的文件描述符的数量。mysql对每个唯一打开的表需要2个文件描述符。

(8)、thread_cache_size

可以复用的保存在中的线程的数量。如果有，新的线程从缓存中取得，当断开连接的时候如果有空间，客户的线置在缓存中。如果有很多新的线程，为了提高性能可以这个变量值。通过比较 connections 和 threads_created 状态的变量，可以看到这个变量的作用。

(9)、mysql的搜索功能

用mysql进行搜索，目的是能不分大小写，又能用中文进行搜索

只需起动mysqld时指定 –default-character-set=gb2312

(10)、wait_timeout

服务器在关闭它之前在一个连接上等待行动的秒数。

注：上面的结果也仅仅是个人一些看法，你可以根据你自己主机的硬件情况（特别是内存大小）进一步修改。

MySQL CPU占用过高怎么办

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

CPU过时（比较旧的CPU）

RAM资源不足（RAM记忆体）

解决办法如下：

①临时解决方案

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

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

右击移至详细资料

再来右击设定优先顺序

按照下方图二的步骤

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

这个方法只能临时解决

②实际解决方法是更换CPU

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

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

mysql数据库cpu飙升800%，如何故障定位及优化？

mysql数据库cpu飙升800%，基本上就两种原因：

访问量大，大到你8核cpu都承受不了；

慢查询，数据库执行sql语句操作（查询数据、修改数据）会产生大量的逻辑读，将读出来的数据维护到临时表中（内存），系统需要消耗较多的cpu来维持内存与磁盘数据的一致性。

大多数情况下都是开发人员对sql的把握质量不够，导致慢sql查询的产生，进而影响数据库的整体运行状况。

当我们的数据库性能下降的厉害或者cpu飙升时候，可以进行如下操作定位问题：

查询mysql进程列表

获取到mysql当前使用的进程：

如果进程很多，说明请求量很大，需要区分是否正常业务流量，还是代码问题导致的。

查询慢查询日志

找到慢查询日志文件/home/mysql/data3085/mysql/

slow_query.log

避免数据库cpu飙升

实际开发过程中，我们对数据库的使用一定要小心，不能等问题发生了再去排查问题解决问题，而是要预防问题的发生，并且在问题可能发生的情况下，提前介入，避免问题扩大化。平时开发过程中需要做好一些准备工作：

增加CPU使用率告警机制，比如使用率超过80%就短信告警；

所有的sql语句必须走索引，有DBA则由DBA统一，没有的话开发人员先执行explain看sql执行计划，必须走索引，属于强制规则；

新功能上线必须进行压测；

日常mysql运行监控，慢查日志查看，将隐患扼杀在摇篮之中。