2012-07-25 10 views
8

Ich möchte einen Nagios-Watchdog für JVM erstellen, der aussieht, wenn der JVM nicht mehr genügend Arbeitsspeicher hat und ihn neu startet.Wie starte ich JVM neu, wenn der JORM-Speicher nicht mehr ausreicht?

Momentan konnte ich die JVM einrichten JMX erlauben, aber ich weiß nicht, OutOfMemory Zustand zu erkennen und neu zu starten.

/check_jmx -U service:jmx:rmi:///jndi/rmi://127.0.0.1:1100/jmxrmi -O "java.lang:type=Memory" -A "HeapMemoryUsage" -K used -I HeapMemoryUsage -J used -vvvv 
JMX OK HeapMemoryUsage.used=957414288{committed=2415984640;init=2147483648;max=2863333376;used=957414288} 

https://github.com/tcurdt/nagios-check-jmx

+1

leider hat der Standard-jdk _no_ Weg zu erkennen, dass ein jvm OOM getroffen hat. ging das selbst in unserem Produkt durch. Ich habe am Ende einen Logging-Handler installiert, der nach LogRecords sucht, die ein OOME enthalten. funktioniert, solange kein Code den Fehler verschluckt, ohne es zu melden. – jtahlborn

+0

Ich habe einige vielversprechende APIs über die Java Tooling API gefunden, aber ich kam zu dem Schluss, dass jede Lösung die Implementierung von nativem Code in einen Werkzeugagenten beinhalten würde, was für uns ein "No Go" war. – jtahlborn

Antwort

1

Ich glaube nicht, dass Sie einen Out-of-Memory-Zustand in der Lage sein werden unter Verwendung von JMX zu erkennen. Wenn die JVM wirklich am Ende ihres Lebens ist, werden JMX-Verbindungen höchstwahrscheinlich selbst OOM-Ausnahmen auslösen, wenn Sie versuchen, eine Verbindung herzustellen.

Wir erkennen hoch Speicherbedingungen anstelle von OOM. Wir alarmieren, wenn der freie Speicher unserer Systeme für eine bestimmte Zeit unter eine Wassermarke fällt. Wir haben auch Threads, die ausgeführt werden, um Pro-Serve-Metrik-Dateien auszugeben. Da der Thread bereits zugewiesen ist, kann er nach Ablauf der JVM Systemspeicherinformationen zuverlässig ausgeben.

Wir protokollieren:

// free memory 
Runtime.getRuntime().freeMemory() 
// current heap usage 
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory() 
+3

Wenn Sie wissen wollten, ob Ihnen der verfügbare Arbeitsspeicher ausgegangen ist, müssen Sie 'Runtime.getRuntime(). MaxMemory()' nicht verwenden? Seit 'totalMemory()' basiert auf, was die JVM in der JVM in diesem Moment hat (d. H. Es könnte wachsen). Im Wesentlichen verfügbarer Speicher wäre "Runtime.getRuntime(). MaxMemory() - Runtime.getRuntime(). TotalMemory() + Runtime.getRuntime(). FreeMemory() '. –

12

Wenn Sie mit Java 1.4.2 oder höher, mit dieser Option können Sie einen benutzerdefinierten Befehl auszuführen, wenn die erste OutOfMemeory Ausnahme auftritt: -XX:OnOutOfMemoryError="<cmd args>;<cmd args>"

Das sollte gebe dir einige anständige Möglichkeiten. z.B. Sie könnten eine passive Prüfung an Nagios starten, um ihm mitzuteilen, dass der Server neu gestartet wird, und dann ein Shell-Skript starten, um Ihre fehlerhafte JVM zu stoppen/starten.