MySQL闰秒导致MySQL服务器的CPU sys过大

今天,有只哥们碰到一个问题,他来一个从库,只要是开行MySQL,CPU使用率就大高,其中sys占比为比大,具体可见下图。

MySQL 1

留意:他的生环境是物理机,单个CPU,4只Core。

 

遂,他抓取了CPU的史信息,发现CPU飙高约是起2017年1月1日8点10分起之。

MySQL 2

 

可是于仓库底载重并无赛,通过他报告的“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 3

 

结果却显示,无外特别操作,尤其是本部分的,排在首先个之要么MySQL的后台进程。

 

合看来是如此的诡异,MySQL本身几乎没有负载,但是CPU
sys使用率较高,而且,只要关闭MySQL,CPU负载又会减低下去。

 

说到底,还是从/var/log/messages中找到小蛛丝马迹。

MySQL 4

 

联想到前几龙之闰秒新闻,怀疑这是闰秒造成的。

 

实际上,2012年发的闰秒调整事件(2012年6月30日23:59:59)在天下造成了较充分之熏陶,很多网站的服务器的CPU使用率飙升,导致网站于拖延垮。

新生确认为Linux内核版本有欠缺,在展开闰秒调整时可能会见惹系统时钟服务ntpd进程死锁,并促成Linux系统重启。包括SUSE、RedHat等具备Linux
kernel版本在2.6.29盖下且开通了NTP服务的Linux系统都存在本次风险。如并的时钟源对象也中时钟源,理论及未见面有是影响;如一道的时钟源对象为官时钟源,则会有上述风险。

欠缺陷在2012年修复后,在2015年相同的闰秒调整事件中尽管无导致特大的影响。

 

前发生的闰秒调整造成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/

Five different ways to handle leap seconds with NTP

 

PS:闰秒不是23:59:60秒么?为什么该问题出的年月是8碰。
盖23:59:60是格林威治时间,我们是东八区,所有设长8只钟头。

 

网站地图xml地图