1. casa
  2. Domanda e risposta
  3. memoria con Java 1.8 in Tomcat 6 e Tomcat 8

memoria con Java 1.8 in Tomcat 6 e Tomcat 8

2015-09-04 29 views
14

questione connessa: Garbage collector usage when upgrade from Java 6 + Tomcat 6 to Java 8 + Tomcat 8memoria con Java 1.8 in Tomcat 6 e Tomcat 8

Ho una serie di webapps, compilati con Java 8. Se li corro in Tomcat 8, ho un sacco di GC minore collezioni con allocazione di memoria casuale. In Tomcat 6 l'allocazione della memoria è più lineare e stabile (inattiva in entrambi i casi, senza traffico).

Eden Spazio Tomcat 8:

enter image description here

enter image description here

Eden Spazio Tomcat 6:

enter image description here

enter image description here

Sai perché succede?

EDIT 1:

Questi sono i dati di ambiente di produzione con jdk 1.8 e Tomcat 8. CPU è molto alto quasi sempre a causa dei cicli GC. Qualche commento a riguardo?

enter image description here enter image description here

EDIT 2:

Questa è una heapDump Analisis (discarica 1,8 GB): spazio

enter image description here

fonte

2015-09-04 Fran Montero

+0

Con più chiamate GC si utilizza meno CPU. –

+1

@GilianJaosen ogni ciclo del GC richiede CPU (vedere l'immagine di utilizzo della CPU), una perdita di memoria potrebbe portare a una continua garbage collection con un tempo di CPU del 100% e un server inutilizzabile. –

+1

Con 2 versioni principali tra Tomcat 6 e Tomcat 8, la risposta sarebbe qualcosa come "perché hanno cambiato le cose". Cosa succede se hai traffico e Tomcat non è solo inattivo (poiché è ciò che conta davvero). Stai esaurendo la memoria? Le tue prestazioni peggiorano con Tomcat 8? – Kayaman

risposta

2

Questo è l'Eden, non lo spazio di ruolo. Quindi, questa è solo una buona notizia.

Ma quel passo della memoria sembra essere tomcat8 che assegna qualcosa subito dopo un giovane GC. Potrebbe essere una tecnica "a palloncino"? (allocando un grande buffer debolmente referenziato a "sgonfiarsi" rapidamente per garantire un po 'di spazio in caso di pressione della memoria). Può nascondersi anche nei connettori NIO, come nel parametro 'oomParachute' (1 MB per impostazione predefinita, ma è per thread httpprocessor? Se avessi 200 thread min, ciò corrisponderebbe ai 200 MB visti).

Suggerirò solo che è possibile eseguire il drill nel log delle modifiche per trovare nuove cose o modifiche che si potrebbero ritenere implementate in modo dispendioso come tale meccanismo a palloncino.

ANCHE: è necessario eseguire il tomcat6 in jdk8 per vedere se è veramente Tomcat8 in errore. Lo spazio eden potrebbe essere ingrandito, nel caso in cui G1GC sia così aggressivo da sentirsi obbligato a GC quando viene utilizzato solo 200 MB.

fonte

2016-02-07 14:13:54 user2023577

+0

Grazie per la risposta. Come ho detto nel post, eseguo le stesse app su tomcat 6 e tomcat 8. Il comportamento "extrange" si verifica solo con tomcat 8. Ho trovato il problema con Javosize, guarda la mia risposta. –

1

Grazie a tutti ragazzi per il vostro tempo. Alla fine, il problema è un bug in tomcat 8.0_23. Utilizzando Javosize, ho visto un filo consumando quasi tutto il tempo di CPU:

enter image description here

cercando su internet ho trovato questo Tomcat AJP Bug

In adittion, ho provato Tomcat 8.0_32 e quel filo Poller lo fa nemmeno esiste così risolto problema.

Saluti

fonte

2016-02-19 11:47:43

 Problemi correlati

  • Nessun problema correlato^_^