Heim >Java >Wie kann die JVM nach einem SIGSEGV-Absturz schnell beendet werden?

Wie kann die JVM nach einem SIGSEGV-Absturz schnell beendet werden?

WBOY
WBOYnach vorne
2024-02-09 19:09:091056Durchsuche

Der PHP-Editor Xigua gibt Ihnen die Antwort. Wenn die JVM auf einen SIGSEGV-Absturz stößt, können Sie einige Maßnahmen ergreifen, um den Vorgang schnell zu beenden. Erstens können Sie den JVM-Parameter -XX:+CrashOnOutOfMemoryError festlegen, um einen Absturz und ein schnelles Beenden der JVM zu bewirken, wenn der Speicher überläuft. Zweitens können Sie den Ausnahmebehandlungsmechanismus von Java verwenden, um SIGSEGV-Ausnahmen abzufangen, und die Methode System.exit() aufrufen, um das Programm nach dem Abfangen der Ausnahme zu beenden. Darüber hinaus können Sie die JNI-Schnittstelle auch verwenden, um mit dem Betriebssystem zu interagieren und ein schnelles Beenden zu erreichen, indem Sie die vom Betriebssystem bereitgestellte Exit-Methode aufrufen. Kurz gesagt: Durch die richtige Einstellung der JVM-Parameter und die Verwendung geeigneter Mechanismen zur Ausnahmebehandlung kann die JVM nach einem SIGSEGV-Absturz schnell beendet werden und die Stabilität und Zuverlässigkeit des Programms verbessern.

Frageninhalt

Einer unserer Dienste stürzt aufgrund einiger Probleme mit Tensorflow Java häufig ab. Damit können wir leben (k8s wird es in vielen Fällen neu starten). Das Problem besteht darin, dass die Beendigung des JVM mehrere Minuten dauert. Gibt es eine Möglichkeit, ein schnelles Beenden von sigsegv im nativen Code zu erzwingen?

corrupted size vs. prev_size while consolidating
#
# a fatal error has been detected by the java runtime environment:
#
#  sigsegv (0xb) at pc=0x00007fe4f321a898, pid=1, tid=545
#
# jre version: openjdk runtime environment zulu21.28+85-ca (21.0+35) (build 21+35)
# java vm: openjdk 64-bit server vm zulu21.28+85-ca (21+35, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# problematic frame:
# c  [libc.so.6+0x28898]  abort+0x178
#
# core dump will be written. default location: /data/core
#
# an error report file with more information is saved as:
# /data/hs_err_pid1.log

Ein paar Minuten später:

# [ timer expired, abort... ]
[thread 1037 also had an error]

Workaround

Fügen Sie die folgenden JVM-Optionen hinzu:

-xx:+suppressfatalerrormessage -xx:-createcoredumponcrash

Dadurch wird die JVM gezwungen, sofort auf sigsegv zu beenden, ohne einen Fehlerbericht oder Core-Dump zu erstellen. Wenn die schwerwiegende Fehlermeldung weiterhin angezeigt werden soll, ersetzen Sie -xx:+suppressfatalerrormessage 替换为 -xx:errorlogtimeout=1.

Ich vermute, dass dieser JVM mit einem ziemlich großen Heap (> 64 GB) läuft und dass das Schreiben der Core-Dump-Datei bei einem Prozess, der so viel Speicher beansprucht, nur eine Weile dauert:

# Core dump will be written. Default location: /data/core

Während der wenigen Minuten, die es dauert, sehen Sie möglicherweise, wie die Core-Dump-Datei am oben genannten Speicherort wächst (dies wäre eine einfache Möglichkeit, diese Theorie zu bestätigen).

Die Abhilfe besteht darin, die Erstellung von Core-Dump-Dateien zu deaktivieren, deren Details von Ihrem spezifischen Betriebssystem abhängen (Core-Dumps können jedoch auf fast jedem Unix-basierten Betriebssystem deaktiviert werden). Darüber hinaus kann es an diesem bestimmten Speicherort zu dateisystembezogenen Engpässen kommen, die dazu führen, dass der Core-Dump langsamer als erwartet geschrieben wird.

Das obige ist der detaillierte Inhalt vonWie kann die JVM nach einem SIGSEGV-Absturz schnell beendet werden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:stackoverflow.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen