Ich habe Tomcat Web App auf VPS und der Tomcat manchmal (etwa einmal im Monat) stürzt mit dem folgenden Fehler in catalina.out ab:
Warnung für Java HotSpot (TM) 64-Bit-Server-VM: Die Ausnahme java.lang.OutOfMemoryError ist beim Senden des Signals SIGTERM an den Handler aufgetreten. Möglicherweise muss die VM zwangsweise beendet werden.
Hier sind einige Details zu meiner Konfiguration:
VPS: debian-5.0-x86_64
RAM: 2,5 GB,
virtuelle Prozessoren: 8
HDD: 60 GB Festplatte - 70% kostenlos
Tomcat 7.0
Java-Version:
%Vor%Java-Parameter: -Xms512m -Xmx1024m
Ich habe auch Apache-PHP auf diesem Server.
Ich überwache die Serverlast mit Munin und es zeigt mir, dass die Speicher- und CPU-Auslastung immer stabil ist und es vor dem Absturz keine Erhöhungen gab.
Ich protokolliere auch die Java-Speicherbelegung über die java.lang.Runtime-Klasse, und es zeigt, dass jvm immer max200Mb Speicher verwendet und es vor dem Absturz keine Erhöhung gab. Das letzte Protokoll vor dem Absturz war vor 40 Sekunden und dieser Zeit verwendete Speicher war: 152Mb.
Meine Web-App führt auch 6-7 Threads aus, die Daten von verschiedenen öffentlichen APIs sammeln. Diese Threads starten, wenn Tomcat gestartet wird, und sie werden immer mit periodischen Schlägen ausgeführt.
Können Sie mir bitte sagen, warum es abstürzt? Wie kann ich den Grund finden?
Führen Sie top von der Shell aus und sehen Sie, wie viel Speicher Linux beansprucht
Java-Prozess wird aufgenommen.
Überprüfen Sie die Gesamtspeicherauslastung auf dem Computer. Es könnte so sein Andere Prozesse verbrauchen den gesamten Speicher und zwingen Linux zum Töten die JVM: Eine Datenbank wie Mysql oder Postgress ist wahrscheinlich ein Verdächtiger.
Überprüfen Sie /var/log/messages in den Zeitabschnitten um die Abstürze herum
ungewöhnliche Ereignisse.
Sie können die Datei service.bat oder service.sh (im bin-Ordner der Verteilung) bearbeiten und die folgenden beiden jvm-Parameter eingeben
%Vor%Der PATH_TO_WRITE_DUMP sollte die notwendigen Berechtigungen haben, Sobald Sie die Heap-Dump-Datei erhalten haben, die im Falle eines OutOfMemory-Problems generiert wird, analysieren Sie sie entweder von Hand oder mit Hilfe von Drittanbieter-Tools. Sie können diese Datei in jvisualvm laden und eine Analyse durchführen oder Sie können das Memory-Analyzer-Plugin von Eclipse verwenden, es ist sehr nützlich und gibt einige potentielle Speicherleckverdächtige und Dominatorbäume (d. H. Welches Objekt den Heap dominiert) Dies kann ein guter Ausgangspunkt sein.
erhöhen Sie Tomcat Java Startup-Speicher, wie: setze JAVA_OPTS = -server -Xms256m -Xmx512m
Lässt sich davon entfernen:
Die Ausnahme java.lang.OutOfMemoryError ist aufgetreten, wenn das Signal SIGTERM an den Handler gesendet wurde - die VM muss möglicherweise zwangsweise beendet werden.
Zunächst sieht es so aus, als hätte der JVM (Tomcat) ein SIGTERM-Signal gesendet. Es muss etwas außerhalb der JVM sein, die das getan hat. Eine JVM sendet keine Signale an sich 1 .
Sie müssen also herausfinden, was das macht. Mein erster Tipp wäre der OOM-Killer ... aber der OOM-Killer benutzt SIGKILL nicht SIGTERM. Und die JVM sieht die SIGKILL nie kommen!
(Sie können bestätigen, dass es sich nicht um den OOM-Killer handelt, indem Sie in "/ var / log / messages" suchen ... oder wo auch immer Ihr System Kernel-Nachrichten protokolliert. Siehe Wie man den Linux-Speichermörder konfiguriert )
Wenn es nicht der OOM-Killer ist, gibt es ein paar Möglichkeiten, die Quelle eines Signals zu finden:
Und sobald Sie die Quelle des Signals haben, werden Sie Hinweise haben, warum es gesendet wurde.
Die andere bemerkenswerte Sache ist, dass OutOfMemoryError bei der Handhabung von SIGTERM auftrat. Dies legt (für mich) nahe, dass die Ursache dafür ist, dass Tomcat zu viel Speicher verbraucht hat und dass es ein SIGTERM gesendet hat, damit es (sauber) verschwindet. Ich nehme an, dass die JVM dann zum Betriebssystem geht, um ein wenig mehr Speicher zu verlangen (um mit dem SIGTERM umzugehen), und das Betriebssystem sagt "Nein", und die JVM wirft ein OutOfMemoryError . Leider befindet sich die JVM jetzt in einem Zustand, in dem sie weder sauber austreten noch sich erholen kann. Daher heißt es "die VM muss möglicherweise zwangsweise beendet werden".
Jedenfalls. Das sieht für mich wie eine eher ungewöhnliche Manifestation eines gängigen Java-Problems aus. Sie haben wahrscheinlich einen Fehler in den Webapps, die in Ihrem Tomcat ausgeführt werden und Speicher verlieren. Wenn das der Fall ist, ist die einzige wirkliche Lösung, den Fehler zu finden und zu beheben. (Wenn Sie die Größe des Heapspeichers erhöhen, wird das Problem nach Möglichkeit nur beseitigt. Es kann das Intervall zwischen den Abstürzen verringern, es ist jedoch unwahrscheinlich, dass es sie verhindert.)
Angenommen, Sie sind bereit, in den sauren Apfel zu beißen:
1 - Es sei denn, etwas macht etwas natives im nativen Code ...
Tags und Links java out-of-memory tomcat7 jvm-crash