2012年7月1日のうるう秒のあとに、MySQLやJavaなどのCPU使用率が高騰する事象が報告されています。
うるう秒を跨いでいな場合でも発生するようです。
７月１日時点では、CentOS6.3、MySQL5.1の組み合わせでは問題なかったのですが、MySQLを5.5にバージョンアップしてしばらくすると、MySQLのCPU使用率が１５０％前後まで上がったために原因の特定が出来ていませんでした。
top – 14:43:31 up 122 days, 22:20, 3 users, load average: 1.25, 1.43, 0.89
Tasks: 188 total, 1 running, 187 sleeping, 0 stopped, 0 zombie
Cpu(s): 36.4%us, 1.5%sy, 0.0%ni, 60.9%id, 1.1%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 4055056k total, 3840116k used, 214940k free, 19248k buffers
Swap: 2096472k total, 137464k used, 1959008k free, 317536k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14516 mysql 20 0 2288m 1.2g 3916 S 154.4 31.0 23:59.21 mysqld
18927 apache 20 0 434m 58m 5288 S 18.6 1.5 23:17.67 httpd
30665 apache 20 0 438m 60m 5464 S 1.7 1.5 21:08.93 httpd
1244 root 20 0 81296 1308 628 S 0.3 0.0 60:44.27 perl
1422 root 20 0 81308 1256 604 S 0.3 0.0 10:10.19 perl
22221 root 20 0 84004 2248 832 S 0.3 0.1 163:38.12 perl
1 root 20 0 19204 352 168 S 0.0 0.0 0:30.24 init
MySQLが被害を受けているので調べていたのですが、原因はLinuxカーネルの不具合とのことです。
•LKML: John Stultz: [PATCH] [RFC] Potential fix for leapsecond caused futex related load spikes
対処法は、サーバを再起動するか、以下のコマンドを入力して日付フォーマットの再設定を行います。
# date `date +'%m%d%H%M%C%y.%S'`
MySQLの場合、MySQL 5.5においてsrv_lock_timeout_threadとsrv_error_monitor_threadというバックグラウンドスレッドがこの不具合により暴走します。MySQL 5.1についてはこれらのバックグラウンドスレッドがfutex(2)を利用していないため、CPU使用率の高騰は発生しませんでした。
MySQL Bugs: #65778: User has reported large and continued spike in CPU after leap second