Heute morgen um 2.00 Uhr haben uns einige Server ordentlich Probleme bereitet. Prozesse wie ksoftirqd haben überdurchschnittlich viel CPU konsumiert und die Load ging raketenhaft nach oben. Ein kurzer Blick auf den Graphen und der Vergleich mit anderen Systemen lässt den Zeitpunkt auch schnell lokalisieren.
Was genau dann aber um 2.00 Uhr passiert ist, war dann im Logfile zu sehen.
Jul 1 01:59:59 icinga-web kernel: [725419.171543] Clock: inserting leap second 23:59:60 UTC
Jul 1 02:11:33 icinga-web ntpd[2027]: kernel time sync status change 0001
Ursache war eine sogenannte Schaltsekunde, welche nachfolgend (ich zitiere Wikipedia) erläutert wird.
Eine Schaltsekunde ist eine bei Bedarf in die Koordinierte Weltzeit UTC zusätzlich eingefügte Sekunde, um sie mit der Universellen Sonnenzeit UT1 zu synchronisieren (dUT1 < 0,9 s). Sie wird vom Internationalen Dienst für Erdrotation und Referenzsysteme (IERS) festgelegt und eingeführt.
Was genau passiert wird noch auf einen Buglisten und im IRC diskutiert aber grundsätzlich sind wohl entsprechende Linux-Locks (Futex) und deren Timeout durch die Umstellung für die Konsumierung der CPU verantwortlich. Mit folgenden Commands lässt sich das Problem lösen und die Load nähert sich umgehend wieder an normale Werte an.
/etc/init.d/ntp stop; export LANG="en_EN"; date -s "`date`"; touch /tmp/leap_second ; /etc/init.d/ntp start
Hier noch ein paar Links zu Thema welches heute morgen nicht nur uns, sondern auch Amazon AWS, den Flughafen Sydney und viele große ISPs betroffen hat:
- Hohe Auslastung MySQL
- MySQL and the Leap Second
- Leap Second in Red Hat
- Fatale Sekunde
- Linux Kernel List
- Chaos am Flughafen von Sydney
Vielen Dank an unsere Managed Service Truppe, speziell Marcus und Sebastian für die tolle Arbeit. Noch allen einen schönen Sonntag.