2011-11-16 11 views
5

Quindi ogni due giorni il mio processo java su Ubuntu viene ucciso automaticamente, e non riesco a capire perché.Qualcosa continua a uccidere il mio processo Java su Ubuntu, qualcuno sa 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".

+0

La RAM fisica massima non equivale a quanto può utilizzare un processo. Eric Lippert ha avuto un ottimo post su questo . So che il post è centrato su Windows/.NET, ma è anche interessante. Solo per curiosità, puoi tentare di catturare un OutOfMemoryError e registrarlo per confermare/negare che questa sia la causa? –

+1

Sto registrando stdout e stderr, che credo sia dove andrebbe una OOM, e non vedo nulla che indichi un'eccezione di OOM ... Nella mia esperienza un OOM ha come risultato che l'app ha smesso di funzionare, non essendo stata uccisa. In questo caso, sembra che l'app sia stata uccisa dal sistema operativo. – sanity

risposta

5

(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.

+1

In che modo lo dice il syslog collegato? La console dice che java è stato ucciso, non che ha smesso. Se avesse esaurito la memoria, in genere genererebbe un'eccezione OutOfMemory, che non era così. Sono in esecuzione con un heap così grande perché ho bisogno di memorizzare milioni di oggetti ciascuno dei quali richiede diversi kilobyte di RAM. – sanity

+0

@sanity - leggi di nuovo ... –

+0

Per qualche altro consiglio Sto riducendo l'utilizzo massimo della memoria a 15 GB – sanity

1

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.

+0

oops errato, è in realtà 11 GC completi, ma questo è ancora un bel po '. è sicuramente una OOM e dovresti provare a ridurre la dimensione dell'heap. – aishwarya

+0

Spiacente, non vedo dove il gist indica una OOM, non riesco a vedere nessuna OOM in stdout o stderr per il processo: -/Perché è importante che l'intero heap utilizzi solo il 50% della RAM? Sicuramente il -Xmx specifica la RAM massima che Java utilizzerà? – sanity

+0

..anche, non ridurre la dimensione dell'heap * aumenta * la probabilità di una OOM? – sanity

2

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.

+0

Ho aggiornato la mia domanda con le informazioni richieste – sanity

6

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.

+0

Puoi riassumere perché l'OOM-killer ucciderebbe un'app utilizzando solo 28 GB su una macchina con 35 GB di RAM e praticamente nessun altro processo in esecuzione su di essa? – sanity

+0

vedere anche http://stackoverflow.com/questions/15237067/how-do-i-configure-oom-killer – yegor256

Problemi correlati