☰

OOM-Killer, JBoss und Kernel Panic

tag-icon • tag-icon redhat jboss vmware-esx 32-bit oom
OOM-Killer, JBoss und Kernel Panic

Wir verwenden RedHat 3.4.6 (x32) auf VMWareEsx3.5 (x64) mit 6 GB RAM. Im Hintergrund laufen einige Java-Prozesse (einschließlich JBoss).

Das Problem besteht darin, dass die Java-Prozesse viel Speicher verbrauchen und manchmal vom OOM-Killer beendet werden. Wenn der OOM-Killer aktiv wird, ist der freie physische Speicher sehr gering (100–200 MB), aber der Swap wird nicht verwendet (99 % frei). Manchmal verursacht dies auch eine Kernel-Panik.

  • Warum wird der Swap also nicht verwendet?
  • Wie untersucht man diese Kernel-Panic?
  • Ist die Verwendung von 6 GB Speicher auf einem 32-Bit-Redhat sinnvoll?

Danke

Antwort1

Persönlich würde ich PAE nie verwenden (über 4 GB RAM auf einem 32-Bit-System). Mit einem echten 64-Bit-Kernel und -System kommen Sie deutlich besser voran.

OOM sollte nur ausgelöst werden, wenn ein Malloc fehlschlagen könnte. (Nicht, wenn viel Swap verfügbar ist.)

Der 32-Bit-Kernel ist wahrscheinlich ein Teil der Ursache. PAE verwendet unterschiedliche Speicherzonen und es kann sein, dass eine Zone kein Malloc von einer anderen Zone ausführen darf.

Haben Sie Ihre Swappiness geändert? (Wie bereitwillig der Kernel Swap verwendet.) cat /proc/sys/vm/swappiness?

Sie können auch die Optimierung von vm.dirty_ratio oder vm.lower_zone_protection = 100 in Betracht ziehen.

Haben Sie den Kernel-Panic erfasst? (Eine serielle Konsole ist hierfür häufig eine gute Möglichkeit.)

Sie können auch versuchen, dem OOM-Killer mit Ihrer eigenen Prozessüberwachungssoftware zuvorzukommen. (sehen Sie sich Monit an.)

Viel Glück

Antwort2

Aushttp://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002704

RHEL4-virtuelle Maschinen, auf denen Oracle/Java läuft, beenden zufällig Prozesse mit OOM-Killer. Details: OOM-Killer beendet Anwendungen, obwohl ESX nicht unter Speicherauslastung steht. Der Befehl top zeigt, dass viel Speicher zwischengespeichert wird und der Swap-Speicher kaum genutzt wird. Lösung

Wenn die Größe der zu kopierenden Daten die Größe des physischen Speichers überschreitet, beginnt oom-killer, Prozesse nach dem Zufallsprinzip zu beenden.

Dies kann durch Ausführen von:

sysctl -w vm.lower_zone_protection 100

Wenn lower_zone_protection auf 100 gesetzt ist, erhöht es den Schwellenwert für freie Seiten um 100, wodurch die Seitenrückgewinnung früher beginnt und verhindert wird, dass NFS (Network File System) weit hinter den Speicheranforderungen des Kernels zurückbleibt. Dies führt dazu, dass die Seitenrückgewinnung früher erfolgt und die Zonen somit besser „geschützt“ sind. Dieses Problem wurde von Redhat in RHEL erkannt und in den folgenden Artikeln wurde eine Problemumgehung dafür bereitgestellt:

verwandte Informationen