Kann eine hohe Auslastung dazu führen, dass der Server hängt und der Fehler länger als 120 Sekunden blockiert wird?

17

Derzeit laufen einige VMs und 'Baremetal'-Server. Java läuft auf Hochtouren - manchmal über 400%. Zufällig hängt der Server mit dem Fehler in der Konsole "Java - länger als 120 Sekunden blockiert" - kjournald, etc.

Ich kann keine dmesg-Ausgabe erhalten, weil dieser Fehler aus irgendeinem Grund nur in die Konsole schreibt, auf die ich keinen Zugriff habe, da diese remote gehostet wird. Daher kann ich keine vollständige Ablaufverfolgung kopieren.

Ich habe die Umgebung geändert, in der sich das befindet - sogar der physische Server und das passiert immer noch.

Ich habe hung_task_timeout_secs in 0 geändert, falls dies ein falsches Positiv gemäß http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html ist .

Außerdem ist irqbalance nicht installiert, vielleicht würde es helfen?

dies ist Ubuntu 10.04 64bit - dasselbe Problem mit dem neuesten 2.6.38-15-Server und 2.6.36.

Könnten CPU- oder Speicherprobleme / kein Swap-Link dieses Problem verursachen?

Hier ist die Konsolenmeldung:

[58Z?Z1.5?Z840] INFUI task java:21547 blocked for more than 120 seconds.
[58Z?Z1.5?Z986] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z06Z] INFUI task kjournald:190 blocked for more than 120 seconds.
[58Z841.5?Z336] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z600] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z841.5?Z90?] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?3413] INFUI task java:21547 blocked for more than 120 seconds.
[58Z841.5?368Z] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?ZZ36] INFUI task kjournald:60 blocked for more than 120 seconds.
[58Z961.5?Z6Z5] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?31ZZ] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z961.5?3393] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.

linux kernel

— Tee
quelle

15

Ja, das könnte es.

Was dies bedeutet, ist ziemlich eindeutig: Der Kernel konnte die Aufgabe nicht für 120 Sekunden planen. Dies weist auf einen Ressourcenmangel hin, häufig im Zusammenhang mit dem Festplattenzugriff.

irqbalancekönnte helfen, aber das klingt nicht offensichtlich. Können Sie uns die Umgebung dieser Nachricht dmesg, insbesondere den darauf folgenden Stack-Trace, mitteilen?

Darüber hinaus ist dies kein falsches positives Ergebnis. Dies gilt nicht sagen , dass die Aufgabe aufgehängt wird für immer , und die Aussage ist vollkommen richtig. Das bedeutet nicht, dass es ein Problem für Sie ist, und Sie können entscheiden, es zu ignorieren, wenn Sie keine Auswirkungen auf die Benutzer bemerken.

Dies kann nicht verursacht werden durch:

ein CPU-Problem (oder besser gesagt, das wäre ein wahnsinnig unwahrscheinlicher Hardwarefehler),
ein Speicherproblem (sehr unwahrscheinlich ein Hardwarefehler, der aber nicht mehrmals auftreten würde; nicht ein Mangel an RAM als Prozess wäre oom-killed),
ein Mangel an Swap ( oom-killerwieder).

In gewisser Weise können Sie dies auf einen Mangel an Arbeitsspeicher in dem Sinne zurückführen, dass das Entziehen Ihres Systems zum Zwischenspeichern von Daten im RAM mehr E / A verursacht. Aber es ist nicht so einfach wie "kein Speicher mehr".

— Pierre Carrier
quelle

Da in / var / log / dmesg nichts aufgezeichnet wird, habe ich nur das eingefügt, was in der Konsole angezeigt wurde. Wenn dies angezeigt wird, hängt das System zu 100%.

— Tee

Diese Meldung kommt vom Kernel und wird in angezeigt dmesg(wenn sie kürzlich ausreichend protokolliert wurde), da dieser Befehl den Ringpuffer für die Kernelprotokollierung druckt. Hoffentlich wird Ihr syslogSetup es auch irgendwo anmelden /var/log, aber ich konnte nicht wissen, wo.

— Pierre Carrier

Die Nachricht wird NICHT in angezeigt/var/log/dmesg , wird jedoch möglicherweise angezeigt , wenn Sie den dmesgBefehl ausführen . Die Datei wird während des Startvorgangs erstellt und erfasst im Allgemeinen nur Kernel-Meldungen zur Startzeit (die andernfalls möglicherweise aus dem Kernel-Ringpuffer entfernt werden würden). Sie können auch die dort angegebene sysstatRessourcennutzung installieren / aktivieren und anzeigen I / O / iowait, wahrscheinlich im Zusammenhang mit Swap (Sysstat wird bei der Identifizierung helfen.)

— Dr. Edward Morbius

@ Dr.EdwardMorbius Wie beheben wir das? Ich habe ein großes Problem mit unserem Zimbra-Server, der bis vor kurzem in einer Produktionsumgebung einwandfrei lief.

— Einseitige

@Lopsided: Entschuldigung für die Verspätung, ich bin nicht oft hier. Kurz gesagt: Sie müssen Ihren Java-Prozess profilieren und herausfinden, warum er hängt. Garbage Collection ist ein Bereich, in dem ich Probleme (und Erfolge) bei der Optimierung hatte. Suchen Sie nach ergodymics für die JVM-Speicherbereinigung und sehen Sie, dass oracle.com/technetwork/java/javase/gc-tuning-6-140523.html Ich fand, dass das Erhöhen des Haufens erheblich geholfen hat.

— Dr. Edward Morbius

6

sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5

Übernehmen Sie dann die Änderung mit:

sudo sysctl -p

löste es für mich ....

— Nick
quelle

6

Sie sollten erklären, was diese Einstellungen jeweils bewirken.

— Kasperd

6

Dies behebt ein ähnliches Problem, das ich in einer Docker-Umgebung hatte. Ich habe hier eine Erklärung gefunden: blackmoreops.com/2014/09/22/… . "Standardmäßig verwendet Linux bis zu 40% des verfügbaren Speichers für das Zwischenspeichern von Dateisystemen. Nach Erreichen dieser Markierung werden alle ausstehenden Daten vom Dateisystem auf die Festplatte geschrieben, wodurch alle folgenden E / A synchronisiert werden. Zum Ausspeichern dieser Daten auf die Festplatte ist dies der Fall Standardmäßig eine Zeitbegrenzung von 120 Sekunden. In diesem Fall ist das E / A-Subsystem nicht schnell genug, um die Daten mit ... "

— Peter M

2

Ich habe diesen Fehler kürzlich in einem unserer Produktionscluster durchlaufen:

11. November 14:56:41 xxx Kernel: INFO: Task xfsalloc / 3: 2393 für mehr als 120 Sekunden blockiert.

11. November 14:56:41 Xxxx-Kernel: Nicht befleckt 2.6.32-504.8.1.el6.x86_64 # 1

11.11. 14:56:41 xxx: "echo 0> / proc / sys / kernel / hung_task_timeout_secs" deaktiviert diese Nachricht.

..

Bei weiterer Überprüfung der gefundenen sar-Protokolle wurde gleichzeitig die IO-Wartezeit erhöht.

Bei der Überprüfung der Hardware (physische Datenträger) wurden mittlere Fehler und andere SCSI-Fehler auf einem der physischen Datenträger protokolliert, die wiederum die E / A-Vorgänge blockierten, da nicht genügend Ressourcen für die Zuordnung vorhanden waren.

11.11.15 19:52:40: beendet pRdm 607b8000 flags = 0 TimeOutC = 0 RetryC = 0 Request c1173100 Reply 60e06040 iocStatus 0048 retryC 0 devId: 3 devFlags = f1482005 iocLogInfo: 31140000

11.11.15 19:52:40: DM_ProcessDevWaitQueue: Task-Verwaltung in Bearbeitung devId = x 11.11.15 19:52:40: DM_ProcessDevWaitQueue: Task-Verwaltung in Bearbeitung devId = x

Dies lag also an einem Hardwarefehler in unserem Cluster.

Es wäre also gut, wenn Sie nach der Kerndatei suchen könnten und wenn das Dienstprogramm ipmi vorhanden ist, prüfen Sie, ob der Befehl ipmiutil / ipmitool sel elist vorhanden ist, um nach dem Problem zu suchen.

Grüße, VT

— Varun Thomas
quelle

0

Sie können die Überwachungsschnittstelle Ihres Cloud-Anbieters aufrufen und überprüfen, ob Sie die für Ihren Speicher angegebenen maximalen IOps nicht überschritten haben. Dies erklärt, warum das Leeren der Cache-Daten sehr lange gedauert hat.
Die maximalen IOps sind auf der Seite mit den Speicherattributen verfügbar.

— Emmanuel
quelle