Qualcosa continua a uccidere il mio processo Java su Ubuntu, qualcuno sa perché?

Question

Quindi ogni due giorni il mio processo java su Ubuntu viene ucciso automaticamente, e non riesco a capire perché.

La mia scatola ha 35,84 GB di RAM, quando lancio il mio processo Java ho passato il parametro -Xmx28g, quindi dovrebbe usare meno della massima RAM disponibile.

ho corse jstat come segue:

# jstat -gccause -t `pgrep java` 60000 

Le ultime righe di uscita da jstat immediatamente prima che il processo è stato ucciso sono stati:

Time  S0  S1  E  O  P  YGC YGCT  FGC FGCT  GCT  LGCC     GCC 
14236.1 99.98 0.00 69.80 99.40 49.88 1011 232.305 11 171.041 403.347 unknown GCCause  No GC 
14296.2 93.02 0.00 65.79 99.43 49.88 1015 233.000 11 171.041 404.041 unknown GCCause  No GC 
14356.1 79.20 0.00 80.50 99.55 49.88 1019 233.945 11 171.041 404.986 unknown GCCause  No GC 
14416.2 0.00 99.98 24.32 99.64 49.88 1024 234.945 11 171.041 405.987 unknown GCCause  No GC 

Questo sembra essere quello che è andato giù in/var/log/syslog in questo periodo: https://gist.github.com/1369135

Non c'è davvero niente in esecuzione su questo server oltre alla mia app java. Cosa sta succedendo?

modifica: sto eseguendo java versione 1.6.0_20, gli unici parametri notevoli che sto passando a java all'avvio sono "-server -Xmx28g". Non sto utilizzando un server delle applicazioni, ma la mia app incorpora il "framework web semplice".

Answer 1

(secondo tentativo).

Supponendo che il problema sia il killer OOM, ha ucciso il processo in un disperato tentativo di mantenere il sistema operativo in una grave crisi di mancanza di memoria.

Vorrei concludere che:

• JVM è in realtà utilizzando molto più di 28GB; Ad esempio, l'utilizzo della memoria non heap è significativo e

• il sistema operativo non è configurato con un'adeguata quantità di spazio di swap.

Vorrei provare ad aggiungere altro spazio di scambio, in modo che il sistema operativo possa scambiare parti della vostra applicazione in caso di emergenza.

In alternativa, ridurre la dimensione heap della JVM.

---

nota che "-Xmx ..." imposta la dimensione heap massima, non la quantità massima di memoria che il vostro JVM può utilizzare. La JVM mette alcune cose fuori dall'heap, incluse cose come la memoria per stack di thread e file mappati in memoria che l'applicazione sta usando.

Answer 2

wow, puoi davvero avere 28 GB di heap ?! Potrebbe essere che dovresti provare a ridurlo, tenerlo a non più del 50% della RAM che penso (quindi ~ 18 GB, o potrebbe essere anche 15 GB). Plus 171 GC completi sono tantissimi! Quanto è durata questa app? 171 in 2-3 giorni sembra enorme. btw the gist indica una OOM prima della terminazione - penso che ridurre l'heap lo risolva (potresti limitare la JVM dall'espansione dello spazio nativo). Prova ad aggiustare vari parametri, prova ad esempio la dimensione dello stack (-Xss) se necessario. Controlla anche la dimensione massima perm e altre sezioni. È un problema di memoria e potrebbe non essere necessariamente l'heap.

Answer 3

Cosa JVM stai usando? e quale server delle applicazioni? È possibile che stiate allocando troppa memoria, e ciò può essere problematico - il garbage collector potrebbe avere problemi nel fare il suo lavoro.

Non sono sicuro che questo sia il tuo caso, ma ho trovato un articolo interessante this che spiega come Linux domina la memoria.

Answer 4

Benvenuti nel OOM-killer, una 'funzionalità' di Linux che è la rovina delle applicazioni di memoria grande ovunque. Non c'è una semplice ricetta da trattare, basta cercare su google e iniziare a leggere e armare.

Mentre non riesco a mettere le mie dita mentali su una spiegazione concisa dello shenigans del killer OOM, ricordo che il parametro di sintonizzazione critico è chiamato 'swappiness'. Su uno dei nostri grandi server, abbiamo:

/etc/sysctl.conf:vm.swappiness=20

http://www.gentooexperimental.org/~patrick/weblog/archives/2009-11.html Leggi.

Answer 5

Ubuntu ha un processo di "watchdog" che uccide altri processi quando la memoria si esaurisce. Vedere la pagina man: http://manpages.ubuntu.com/manpages/natty/man8/watchdog.8.html