别忘了我们又多活了一秒

 

北京时间7月早上8点左右，集群收到报警，cpu暴增，经过排查发现hadoop集群没有任何job执行，然而CPU基本是满载，非常奇怪。还好现在集群没有在线服务和比较重要的任务处理。排查毫无头绪。

周一上班，打开各类新闻，北京时间7月1日全球于7：59后增加一秒，出现7：59：60的特殊现象，然后是8：00：00。

紧接着就是互联网行业内都不同程度的受到闰秒影响，造成服务器宕机，

经过上网查阅资料,发现是因为操作系统内核在处理闰秒的时候，导致部分试图获取当前系统时间的进程出现Live Lock，也就是说，某个进程/线程在查询系统时间的时候，进入了一种类似死循环的状态，CPU利用率很高，同时不能完成时间查询。

猜测JVM和MySQL试图通过CPU硬件晶振的数据获得当前精确的时间，由于闰秒的关系，这个时间和操作系统维持的墙上时间（Wall Time，也就是显示给用户看的时间）不一致，导致了这个问题。

系统时间对于各种服务器程序尤为重要，hadoop集群节点都定期收集和报告系统状态，如果系统时间无法获取，可能导致部分节点被误判为故障，自动引起一系列不必要的故障恢复动作。

我们首先选择的方式是重启所有服务,但是很显然没有解决问题，后来经过运维部同事排查，我们Linux服务器默认启用Ntp服务器的时间源是centeros的，所以我们先关闭了ntp服务，改由局域网同步，问题可以解决。

当然网上也有解决方案：Mozilla的一篇blog, 也谢谢Google快速灵活的实时索引，我们在重启服务器的过程中，发现了如下更简单的解决办法:

$ cat files/bin/leap-second.sh 
# this is a quick-fix to the 6/30/12 leap second bug

if [ ! -f /tmp/leapsecond_2012_06_30 ]
then
/etc/init.d/ntpd stop; date `date +"%m%d%H%M%C%y.%S"` && /bin/touch /tmp/leapsecond_2012_06_30
fi

这个脚本只是简单的强制重置系统时间，从而让系统中所有时间回到同步的状态。完成后，你可以确认所有服务的状态回到正常，然后手动重启ntp服务。类似mozilla, 我们也使用puppet将该脚本在所有服务器上执行。