MySQL服务进程占用系统CPU达100%

  1. 云栖社区>
  2. 博客>
  3. 正文

MySQL服务进程占用系统CPU达100%

优惠码发放 2017-12-02 11:26:13 浏览2583
展开阅读全文

故障现象:ping云主机严重丢包,丢包率达99%,仅有一两个包可到达;更无法远程;

排查:云主机 CentOS6.4 后台查看CPU占用高达99% 还好能登入系统,操作也并不卡顿;
top查看 mysql服务进程占用CPU达100% 
如图:
mysql

两分钟后,系统卡死;
(若是系统没有卡死的话还可以经确认后重启mysql服务,以结束连接;)

系统卡死无奈只能重启系统;
重启后CPU直线下降:

CPU_hou

不再丢包,远程服务正常;

分析:MySQL服务为何严重占用系统资源?
与MySQL服务配置与管理有关!
登录mysql数据库:
mysql> show processlist;

show processlist 命令的输出结果显示了有哪些线程在运行,可以帮助识别出有问题的查询语句。
Id User Host db Command Time State Info
207 root 192.168.0.20:51718 mytest Sleep 5 NULL

第一列,id,不用说了吧,一个标识,你要kill一个语句的时候很有用。
user列,显示单前用户,如果不是root,这个命令就只显示你权限范围内的sql语句。
host列,显示这个语句是从哪个ip的哪个端口上发出的。呵呵,可以用来追踪出问题语句的用户。
db列,显示这个进程目前连接的是哪个数据库。
command列,显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)。
time列,此这个状态持续的时间,单位是秒。state列,显示使用当前连接的sql语句的状态,很重要的列,后续会有所有的状态的描述,请注意。
state只是语句执行中的某一个状态,一个sql语句,已查询为例,可能需要经过copying to tmp table,Sorting result,Sending data等状态才可以完成。
info列,显示这个sql语句,因为长度有限,所以长的sql语句就显示不全,但是一个判断问题语句的重要依据。
常见问题 :
一般是睡眠连接过多,严重消耗mysql服务器资源(主要是cpu, 内存),并可能导致mysql崩溃。
(所以说DBA要尽职尽责)
解决办法 :
mysql的配置my.ini文件中,有一项: 
wait_timeout, 即可设置睡眠连接超时秒数,如果某个连接超时,会被mysql自然终止。 
wait_timeout过大有弊端,其体现就是MySQL里大量的SLEEP进程无法及时释放,拖累系统性能,不过也不能把这个指设置的过小,否则你可能会遭遇到“MySQL has gone away”之类的问题,通常来说,我觉得把wait_timeout设置为10是个不错的选择,但某些情况下可能也会出问题,比如说有一个CRON脚本,其中两次SQL查询的间隔时间大于10秒的话,那么这个设置就有问题了(当然,这也不是不能解决的问题,你可以在程序里时不时mysql_ping一下,以便服务器知道你还活着,重新计算wait_timeout时间):
mysql> show global variables like 'wait_timeout'; 
+----------------------------+-------+ 
| Variable_name | Value | 
+----------------------------+-------+

mysql> set global wait_timeout=20;
至此,mysql占用cpu下降了

拓展:停止MySQL服务后进程若还在,则可以杀死进程

网友评论

作者关闭了评论
优惠码发放
+ 关注