闰秒导致MySQL服务器的CPU sys过高
2017-01-04 19:54
483 查看
今天,有个哥们碰到一个问题,他有一个从库,只要是启动MySQL,CPU使用率就非常高,其中sys占比也比较高,具体可见下图。
注意:他的生产环境是物理机,单个CPU,4个Core。
于是,他抓取了CPU的历史信息,发现CPU飙高大概是从2017年1月1日8点10分开始的。
但是这个从库的负载并不高,通过他反馈的“show processlist”和“show engine innodb status\G”的结果可以看出来
show processlist
show engine innodb status
在这里,只截取了“row operations”这一部分
再次回到CPU sys态较高的事实上,一般sys较高就意味着系统在频繁调用内核代码。如果是这样的话,通过perf top就能定位系统什么操作执行得比较多。
结果却显示,无任何异常操作,尤其是内核部分的,排在第一位的还是MySQL的后台进程。
一切看来是如此的诡异,MySQL本身几乎没有负载,但是CPU sys使用率较高,而且,只要关闭MySQL,CPU负载又会降下来。
最后,还是从/var/log/messages中找到些许蛛丝马迹。
联想到前几天的闰秒新闻,怀疑这个是闰秒造成的。
事实上,之前也发生了闰秒导致MySQL服务器CPU sys飙高的问题,
具体可参考:
https://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/
解决方法:
1. 重启服务器
2. 重新设置时间
/etc/init.d/ntpd stop; date -s now
很明显,第2种方法更实用。
重新设置时间后,CPU sys负载马上下降了。
那么,如何避免此类问题的发生呢?
简单方法:
在发生闰秒前停掉ntpd服务,发生后再开启ntpd
其它较优雅的方法,可参考:
https://www.percona.com/blog/2016/12/27/prepare-for-the-new-leap-second/
PS:闰秒不是23:59:60秒么?为什么该问题发生的时间是8点。
因为23:59:60是格林威治时间,我们是东八区,所有要增加8个小时。
注意:他的生产环境是物理机,单个CPU,4个Core。
于是,他抓取了CPU的历史信息,发现CPU飙高大概是从2017年1月1日8点10分开始的。
但是这个从库的负载并不高,通过他反馈的“show processlist”和“show engine innodb status\G”的结果可以看出来
show processlist
mysql> show processlist; +-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------------+------------------+ | 1 | system user | | NULL | Connect | 57892 | Waiting for master to send event | NULL | | 2 | system user | | NULL | Connect | 23 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL | | 108 | root | localhost | NULL | Query | 0 | NULL | show processlist | +-----+-------------+-----------+------+---------+-------+-----------------------------------------------------------------------------+------------------+ 3 rows in set (0.00 sec)
show engine innodb status
在这里,只截取了“row operations”这一部分
... -------------- ROW OPERATIONS -------------- 0 queries inside InnoDB, 0 queries in queue 1 read views open inside InnoDB Main thread process no. 3034, id 140218088003328, state: waiting for server activity Number of rows inserted 7500, updated 237481, deleted 884, read 31371340 0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s ---------------------------- ...
再次回到CPU sys态较高的事实上,一般sys较高就意味着系统在频繁调用内核代码。如果是这样的话,通过perf top就能定位系统什么操作执行得比较多。
结果却显示,无任何异常操作,尤其是内核部分的,排在第一位的还是MySQL的后台进程。
一切看来是如此的诡异,MySQL本身几乎没有负载,但是CPU sys使用率较高,而且,只要关闭MySQL,CPU负载又会降下来。
最后,还是从/var/log/messages中找到些许蛛丝马迹。
联想到前几天的闰秒新闻,怀疑这个是闰秒造成的。
事实上,之前也发生了闰秒导致MySQL服务器CPU sys飙高的问题,
具体可参考:
https://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/
解决方法:
1. 重启服务器
2. 重新设置时间
/etc/init.d/ntpd stop; date -s now
很明显,第2种方法更实用。
重新设置时间后,CPU sys负载马上下降了。
那么,如何避免此类问题的发生呢?
简单方法:
在发生闰秒前停掉ntpd服务,发生后再开启ntpd
其它较优雅的方法,可参考:
https://www.percona.com/blog/2016/12/27/prepare-for-the-new-leap-second/
PS:闰秒不是23:59:60秒么?为什么该问题发生的时间是8点。
因为23:59:60是格林威治时间,我们是东八区,所有要增加8个小时。
相关文章推荐
- 闰秒导致MySQL服务器的CPU sys过高
- mysql占用服务器cpu过高的原因以及解决办法
- ubuntu mysql5.6 数据库占用CPU过高导致机器卡死
- mysql占用服务器cpu过高的原因以及解决办法
- mysql占用服务器cpu过高的原因以及解决办法
- [转] thttpd服务器在时间修改后导致CPU占用率过高的问题
- mysql 没有索引导致的cpu过高
- 黄聪:MYSQL使服务器内存CPU占用过高问题的分析及解决方法
- 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程
- 闰秒导致部分 Linux 服务器高 CPU 使用率
- 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程
- 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程
- mysql占用服务器cpu过高的原因以及解决办法
- thttpd服务器在时间修改后导致CPU占用率过高的问题
- mysql占用服务器cpu过高的原因以及解决办法
- 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程
- WMI 查询服务导致服务器CPU非常高!
- JAVA中hashmap.get()导致CPU占用过高问题
- 生产线上mysql占CPU过高排查实战