Viene visualizzato il messaggio "Java HotSpot (TM) 64-Bit Server Avviso VM: eccezione java.lang.OutOfMemoryError si è verificato il segnale di invio SIGTERM al gestore" in tomcat

Question

Ho l'app Web Tom su VPS e il tomcat a volte (circa una volta al mese) si blocca con il seguente errore nel catalina.out:

avvisi VM Server a 64 bit

Java HotSpot (TM): eccezione java.lang.OutOfMemoryError verificato invio SIGTERM segnale handler- VM può essere necessario forzatamente terminato .

Ecco alcuni dettagli circa la mia configurazione:

• VPS: debian-5,0-x86_64

• RAM: 2,5 GB,

• processori virtuali: 8

• HDD: 60 gb hdd - 70% gratuito

• Tomcat 7.0

• java -version:

  java version "1.6.0_18" 
  OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze1) 
  OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 
  

• Java params: -Xms512m Xmx1024m

Ho anche Apache-PHP su quel server.

Sto monitorando il carico del server con Munin e mi mostra che l'utilizzo della memoria e della CPU è sempre stabile e che non ci sono stati aumenti prima del crash.

Sto anche registrando l'utilizzo della memoria java tramite la classe java.lang.Runtime, e mostra che jvm usa sempre la memoria max200Mb e non ci sono stati aumenti prima del crash. L'ultimo log prima del crash era 40 secondi fa e quella volta la memoria utilizzata era: 152Mb.

La mia app Web esegue anche 6-7 thread che raccolgono dati da diverse API pubbliche. Questi thread iniziano all'avvio di tomcat e funzionano sempre con sleep periodici.

Puoi dirmi perché si blocca? Come posso trovare la ragione?

Answer 1

• Run top dal guscio e vedere la quantità di memoria di Linux sostiene il processo di Java sta prendendo.

• Controllare l'utilizzo complessivo della memoria nella macchina. Potrebbe essere che altri processi stiano consumando tutta la memoria, costringendo Linux ad uccidere la JVM : un database come Mysql o Postgress è un probabile sospetto.

• Controllare /var/log/messages nei periodi di tempo intorno agli arresti anomali per eventi insoliti .

Answer 2

È possibile modificare il servizio.bat o il servizio.file di sh (che si trova nella cartella bin del deistribution) e mettere il sotto dei due parametri JVM

XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<PATH_TO_WRITE_DUMP> 

Il PATH_TO_WRITE_DUMP deve avere le autorizzazioni necessarie, Una volta che il file di heap dump che viene generato in caso di un problema OutOfMemory, analizzarlo a mano o con alcuni strumenti di terze parti. Puoi caricare questo file in jvisualvm e fare qualche analisi o puoi usare Memory-Analyzer-Plugin di eclipse, è molto utile e fornisce alcuni potenziali sospetti di perdita di memoria e alberi dominatori (cioè quale oggetto domina l'heap) Questo può essere un buon punto di partenza

Answer 3

aumento si Tomcat memoria di avvio java, come: set JAVA_OPTS = -server -Xms256m -Xmx512m

Answer 4

Consente scucire questo:

Eccezione java.lang.OutOfMemoryError verificato dispacciamento SIGTERM segnale handler- potrebbe essere necessario terminare forzatamente la VM.

Prima di tutto, sembra che qualcosa abbia inviato al processo JVM (Tomcat) un segnale SIGTERM. Deve essere qualcosa di esterno alla JVM che lo ha fatto. Una JVM non invia segnali a se stessa .

Quindi è necessario capire cosa sta facendo. La mia supposizione prima sarebbe l'assassino di OOM ... ma il killer di OOM usa SIGKILL non SIGTERM. E la JVM non vede mai arrivare SIGKILL!

(Si può confermare che non è il killer OOM, cercando in "/ var/log/messages" ... o dovunque i log di sistema messaggi del kernel. Vedere How to Configure the Linux Out-of-Memory Killer)

Se non è l'OOM assassino, poi ci sono alcuni modi per trovare la fonte di un segnale:

• Finding the source of signals on Linux with strace, auditd, or systemtap

E una volta che si ha la sorgente del segnale, si dovrà indizi utili a capire il motivo per cui è stato inviato.

---

L'altra cosa da notare è che il OutOfMemoryError si è verificato durante la manipolazione del SIGTERM. Questo suggerisce fortemente (per me) che la causa principale è che qualcosa ha rilevato che Tomcat sta usando troppa memoria e gli ha inviato un SIGTERM per farlo andare via (pulito). Suppongo che quello che succede poi è che la JVM va al sistema operativo per chiedere un po 'di memoria in più (per gestire SIGTERM) e il sistema operativo dice "No", e la JVM lancia un OutOfMemoryError. Sfortunatamente, la JVM è ora in uno stato in cui non può né uscire in modo pulito né ripristinare. Quindi dice "potrebbe essere necessario terminare forzatamente la VM".

---

In ogni caso. Questo mi sembra una manifestazione piuttosto insolita di un problema Java comune. Molto probabilmente hai un bug nelle app web in esecuzione nel tuo Tomcat che sta perdendo memoria. Se questo è il caso, l'unica vera soluzione è quella di trovare e correggere l'errore. (Aumentare la dimensione dell'heap ... se possibile ... mette solo il problema fuori. Può ridurre l'intervallo tra i crash, ma è improbabile che li prevenga.)

Supponendo che si è pronti a stringere i denti:

• How to find a Java Memory Leak

---

^{1 - A meno che qualcosa è fare qualcosa di nocciola in codice nativo ...}