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.
Autor: Bernd Erk
Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen Schaschlik-Kultur.
[...] und weitere technische Hintergrund-Informationen zu diesem Software-Probleme finden sich auf dem Netway-Blog. Solltet euer Server auch nach einem Reboot noch Probleme machen so steht euch unser Support gerne [...]
[...] bei blog-windfluechter.net, bei Netways gab es die Lösung. Dieser Beitrag wurde unter Linux abgelegt und mit Bug, CPU Load, Debian, [...]
Danke … hat mir eine Runde Google erspart.
So macht der Post dann auch Sinn und die Mühen der Anderen haben sich gelohnt.
Hi,
vielen Dank für den Post. Das hat mir den Tag gerettet.
Wir hatten das Problem auf SLES Systemen.
Gruß
Christian
Was für SLES System waren das?
Denn laut dem Novell Support seien die SLES System davon nicht betroffen:
http://www.novell.com/support/kb/doc.php?id=7001865
ui, grade ne mail von hetzner deswegen bekommen. danke für den tip. sofort ausgeführt und klappt scheinbar auch soweit
tausend dank!
Auf meinem Debian Squeeze System lässt sich mit
date -s “`date`”
das Datum nicht neu setzen, da date ein deutsches Datumsformat ausgibt auch wenn ich die LANG Variable setze.
Folgender abgewandelter Befehl hat bei mir problemlos geklappt.
/etc/init.d/ntp stop; date -s “`date -R`”; touch /tmp/leap_second ; /etc/init.d/ntp start
Hier gibts noch ein paar Hintergrundinfos von Heise:
http://www.heise.de/newsticker/meldung/Schaltsekunden-Bug-in-Linux-verschwendet-Strom-1631325.html