Re: INFO: task ... blocked for more than 120 seconds
Jan Kappler <public@jan-kappler.de> wrote:
> derartige Meldungen hatte ich heute auf der Konsole meines Servers. Es
> betrifft verschiedene tasks wie flush, kjournald, nfsd.
> Die Kiste läuft mit Squeeze und Kernel 2.6.32-5-686, hat 256 MB RAM und
> 2 x 2,5" SATA Platten als Soft-RAID1. Drauf laufen ein Apache, nfs, ntp,
> apt-cacher-ng, ramlog.
> Soeben ist mir im Log aufgefallen, das diese Meldungen genau zu der
> Zeit (heute Nacht) generiert wurden, als der md-array data check
> gelaufen ist. Könnte also die Belastung des md-raid durch die
> Überprüfung die Ursache sein?
Ja, absolut.
> Meine Suche brachte verschiedene Informationen zu älteren Kernel zutage.
> Vor einiger Zeit - nach der Umstellung Lenny-Squeeze - hatte ich schon
> mal solche Meldungen.
> Soweit ich das verstehe, handelt es sich um einen Bug des Kernel in
> Bezug auf das Leeren des Caches. Geht das nicht schnell genug, weil
> vielleicht das IO-Subsystem (Platten, Controller) nicht schnell genug
> ist, wird der Timeout von 120 Sekunden überschritten und die Meldung
> erzeugt. Ist das richtig?
Dieser Bug kann das Problem auslösen. Aber nicht alleine.
Getriggert wird diese Ausgabe immer dann, wenn ein Prozess länger als
120 Sekunden (dies ist einstellbar) im Status "D" hängt.
Hier passiert dies z.B. immer dann, wenn der Bandroboter die Tapes
wechselt, dann hängt der mtx-Prozess schon mal 3 Minuten, bis die
Operation durchgelaufen und das Band im Laufwerk korrekt erkannt worden
ist.
Der md-Recheck wird ja im Rahmen eines cronjob gestartet, in dessen
zeitlicher Nachbarschaft andere cronjobs noch laufen oder bald laufen
werden. Je nach Durchsatz und Latenz der Platten und deren Fähigkeit,
die nötigen IOPS zu liefern und der Anzahl der Prozesse, die versuchen
zu einem Zeitpunkt X I/O zu machen, kann es schon passieren, dass bei
dir zu dem Zeitpunkt ein Engpass entstanden ist, so dass Prozesse länger
als 120 Sekunden auf das Fertigstellen Ihrer I/O-Anfrage warten mussten.
Und dann gibt es obige Meldung. Solange du diese zeitlich auf ein
spezielles Event (hier "md-recheck") eingrenzen kannst, ist alles i.O.
Kritisch wird es erst dann, wenn diese Meldungen auch im normalen
Betrieb auftreten. Dann ist entweder eine Platte am Sterben oder das
System hoffnungslos überlastet.
Evtl. hilft ein andere I/O-Scheduler wie z.B. deadline anstelle von cfq.
Dies ist aber von der Last auf den Platten abhängig und von der Art und
Weise, wie die Prozesse diese erzeugen.
> Ein "Ronny Egner" schreibt im Oktober 2011 dazu in seinem Blog:
> "The problem is solved in later kernels and there is not “fix” from
> Oracle. I fixed this by lowering the mark for flushing the cache from
> 40% to 10% by setting “vm.dirty_ratio=10″ in /etc/sysctl.conf."
> Okay, ist 2.6.32 schon ein "later"?
2.6.32 wurde am 3. Dezember 2009 released, aktuell ist 2.6.32.61 vom
10.06.2013.
> Ist das Problem unter Wheezy erledigt? Was meint ihr zu diesem
> Vorschlag? Ich würde gern solche "Probleme" lösen beziehungsweise
> abhaken, bevor ich die Kiste auf Wheezy aktualisiere.
Das Cache-Flush-Problem? Das sollte behoben sein.
Andere Ursachen für die Meldung? Nein, je nachdem, was der Grund für die
Meldung ist.
S°
--
Sigmentation fault. Core dumped.
Reply to: