Ich habe Probleme mit dem Absturz von Jetty, ich benutze Jetty 6.1.24.
Ich betreibe eine neo4j Spring MVC webapp, Jetty wird für ca. 1 Stunde laufen und dann muss ich Jetty neu starten. Es läuft auf einer kleinen Amazon ec2-Instanz, Debian mit 1,7 GB RAM.
Ich starte Jetty mit java -Xmx900m -server -jar start.jar
Ich verbinde mich mit dem Server mit putty, wenn Jetty abstürzt die Putty Sitzung trennt, kann ich nicht sehen, welcher Fehler es zum Absturz gebracht hat.
Ich würde gerne sehen können, ob es sich um einen Fehler von Spring handelt, ich bin mir nicht sicher, wie ich die Ausgabe von der Spring-App mit Jetty protokollieren kann. Oder wenn es sich um Jetty oder ein Speicherproblem handelt, was wäre der beste Weg, Jetty zu überwachen? Ich kann das nicht auf meinem lokalen Rechner, auf dem Windows läuft, wiederherstellen. Was denkst du wäre der beste Weg, um das zu erreichen? Danke
Wenn Sie Absturz sagen, meinen Sie die JVM-Segmentierung und verschwindet? Wenn das der Fall ist, würde ich überprüfen und sicherstellen, dass Sie den verfügbaren Speicher der Maschine nicht erschöpfen. Java auf Linux stürzt ab, wenn der Systemspeicher so niedrig wird, dass die JVM nicht mehr bis zu ihrem maximalen Speicher reservieren kann. Beispiel: Sie haben den maximalen JVM-Speicher auf 500 MB festgelegt, von dem derzeit 250 MB verwendet werden. Das Linux-Betriebssystem hat jedoch nur 128 MB zur Verfügung. Dies führt zu instabilen Ergebnissen und die JVM segfault.
Unter Windows verhält sich die JVM in diesem Szenario besser und gibt OutOfMemoryError aus, wenn das System nicht genügend Arbeitsspeicher zur Verfügung hat.
Ich glaube, Jetty verfügt über einen systemeigenen Code für die Bearbeitung von Anfragen mit hohem Volumen. Stellen Sie sicher, dass es nicht verwendet wird. Sie wollen die Abstürze auf Java und NICHT auf irgendeine seltsame native lib isolieren. Wenn Sie das native Zeug herausnehmen und finden, dass es funktioniert, haben Sie Ihre Antwort, was es verursacht. Wenn es weiterhin stürzt, könnte es sehr gut sein, was ich beschreibe.
Sie können die JVM zwingen, den gesamten Speicher beim Start mit -Xms900m zuzuweisen, um sicherzustellen, dass die JVM nicht mit anderen Prozessen um Speicher kämpft. Sobald es den vollen Xmx-Betrag zugewiesen hat, wird es nicht abstürzen. Keine Lösung, aber Sie können es leicht auf diese Weise testen.
Das ist nicht wirklich eine Programmiererfrage; vielleicht wird es zu ServerFault verschoben.
Sie haben nicht ausdrücklich angegeben, welches Betriebssystem Sie verwenden, aber ich riskiere eine Vermutung bei einer Linux-Distribution. Sie haben zwei Möglichkeiten herauszufinden, was falsch ist:
Starten Sie Ihre Sitzung auf dem Bildschirm. Der Bildschirm wird so lange aktiv sein, wie der Computer eingeschaltet ist , bis Sie das Betriebssystem neu starten (oder den Bildschirm beenden).
Sie starten den Bildschirm wie folgt
%Vor% und Sie erhalten eine neue Eingabeaufforderung, wo Sie Ihr Programm starten können (CD Foo, Jetty, etc). Wenn Sie zufrieden sind und Sie nur irgendwo hin müssen, können Sie den Bildschirm trennen, indem Sie STRG + A und dann STRG + D drücken. Sie werden zu dem Ort zurückkehren, an dem Sie vor dem Aufruf von screen waren.
Um zurück zum screen zu kommen, geben Sie screen -R ein, was bedeutet, dass Sie einen bestehenden Bildschirm fortsetzen. Sie sollten den Steg wieder sehen.
Das Schöne ist, dass wenn Sie die Verbindung verlieren (oder Sie Putty durch Zufall oder was auch immer schließen), können Sie screen -list verwenden, um eine Liste der laufenden Bildschirme zu erhalten, und sie dann zwangsweise lösen -D und sie wieder an die current putty -R , kein Schaden angerichtet!
Benutze nohup. Nohup trennt den von Ihnen ausgeführten Prozess mehr oder weniger von der Konsole, sodass keine Ausgabe an das Terminal gesendet wird . Sie starten Ihr Programm normal, aber Sie fügen Ihrem Befehl das Wort nohup hinzu.
Zum Beispiel:
%Vor% Nachdem ls -l abgeschlossen ist, wird Ihre Ausgabe in nohup.out gespeichert.
Wenn Sie java starten, leiten Sie beide Ausgaben (stdout und stderr) in eine Datei um:
Verwenden von Bash:
%Vor%Überprüfen Sie nach dem Absturz diese Dateien.
Wenn der Absturz auf ein Signal zurückzuführen ist (wie SEGV = segmentation fault), sollte es einen Datei-Dump von der JVM an dem Ort geben, an dem Sie java gestartet haben. Für Sun VM (Hotspot) ist es etwas wie hs_err_pid12121.log (hier ist 12121 die Prozess-ID).
Wenn Putty STRONGIG trennt, deutet dies darauf hin, dass auf dem Server nicht mehr genügend Arbeitsspeicher verfügbar ist, und beginnt, Prozesse links und rechts herunterzufahren. Es ist wahrscheinlich Ihre Anlegestelle Instanz wird zu groß.
Das Einfachste, was Sie jetzt tun können, ist das Hinzufügen von 1-2 Gb mehr Swap Space und machen Sie es erneut. Beachten Sie auch, dass Sie den jvisualvm verwenden können, um an die Jetty-Instanz anzuhängen, um Laufzeitinformationen direkt zu erhalten.
Tags und Links java monitoring jetty logging