私たちがまた1秒生き延びたことを忘れないでください.

北京時間の7月朝8時ごろ、クラスタは警報を受け、cpuが急増し、調査の結果、hadoopクラスタにはjobが実行されていないことが分かったが、CPUは基本的に満載で、非常に奇妙だ.クラスタにはオンラインサービスと重要なタスク処理がありません.捜査に糸口がない.
月曜日に出勤して、各種のニュースを開けて、北京時間の7月1日に全世界は7:59後に1秒増加して、7:59:60の特殊な現象が現れて、それから8:00:00です.
次に、インターネット業界では閏秒の影響を受け、サーバがダウンタイムになります.
インターネットで資料を調べたところ、OSカーネルが閏秒を処理している間に、現在のシステム時間を取得しようとしている一部のプロセスにLive Lockが発生していることが分かりました.つまり、あるプロセス/スレッドがシステム時間を照会している間に、デッドサイクルのような状態になり、CPUの利用率が高く、同時に時間照会を完了できなくなりました.
この問題は、JVMとMySQLがCPUハードウェアの水晶振動のデータから現在の正確な時間を取得しようとしていると推測され、この時間は、閏秒の関係でオペレーティングシステムが維持する壁時間(Wall Time、すなわちユーザに表示される時間)と一致せず、この問題を引き起こしている.
システム時間は様々なサーバプログラムにとって特に重要であり、hadoopクラスタノードは定期的にシステム状態を収集し、報告している.システム時間が取得できない場合、一部のノードが故障と誤認され、自動的に一連の不要な故障回復動作を引き起こす可能性がある.
私たちが最初に選んだ方法はすべてのサービスを再起動することですが、明らかに問題を解決していません.その後、運維部の同僚の調査を経て、私たちのLinuxサーバーがデフォルトでNtpサーバーを有効にした時間源はcenterosなので、ntpサービスを閉鎖し、ローカルエリアネットワークの同期に変更しました.問題は解決できます.
もちろんネット上にも解決策があります:Mozillaのブログ、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を使用してすべてのサーバでスクリプトを実行します.