UseConcMarkSweepGC vs UseParallelGC

Question

Attualmente sto avendo problemi con tempi di raccolta dei rifiuti molto lunghi. per favore vedi il seguito La mia attuale configurazione è che sto usando un -Xms1g e -Xmx3g. la mia applicazione utilizza java 1.4.2. Non ho impostato nessun flag di garbage collection. a quanto sembra, 3 GB non è abbastanza e ho davvero un sacco di oggetti da raccogliere.

domanda:

dovrei cambiare il mio algoritmo di raccolta dei rifiuti? cosa dovrei usare? è meglio usare -XX:+UseParallelGC or -XX:+UseConcMarkSweepGC

o dovrei usare questa combinazione

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC 

quelli che occupano la memoria sono rapporti in gran parte i dati della cache dati e non. inoltre, la macchina ha una memoria da 16 GB e ho intenzione di aumentare l'heap a 8 GB.

Quali sono le differenze tra le due opzioni in quanto trovo ancora difficile da capire. la macchina ha più processori. Posso prendere colpi fino a 5 secondi ma da 30 a 70 secondi è davvero difficile.

Grazie per l'aiuto.

Line 151493: [14/Jan/2012:11:47:48] WARNING (8710): CORE3283: stderr: [GC 1632936K->1020739K(2050552K), 1.2462436 secs] 
    Line 157710: [14/Jan/2012:11:53:38] WARNING (8710): CORE3283: stderr: [GC 1670531K->1058755K(2050552K), 1.1555375 secs] 
    Line 163840: [14/Jan/2012:12:00:42] WARNING (8710): CORE3283: stderr: [GC 1708547K->1097282K(2050552K), 1.1503118 secs] 
    Line 169811: [14/Jan/2012:12:08:02] WARNING (8710): CORE3283: stderr: [GC 1747074K->1133764K(2050552K), 1.1017273 secs] 
    Line 175879: [14/Jan/2012:12:14:18] WARNING (8710): CORE3283: stderr: [GC 1783556K->1173103K(2050552K), 1.2060946 secs] 
    Line 176606: [14/Jan/2012:12:15:42] WARNING (8710): CORE3283: stderr: [Full GC 1265571K->1124875K(2050552K), 25.0670316 secs] 
    Line 184755: [14/Jan/2012:12:25:53] WARNING (8710): CORE3283: stderr: [GC 2007435K->1176457K(2784880K), 1.2483770 secs] 
    Line 193087: [14/Jan/2012:12:37:09] WARNING (8710): CORE3283: stderr: [GC 2059017K->1224285K(2784880K), 1.4739291 secs] 
    Line 201377: [14/Jan/2012:12:51:08] WARNING (8710): CORE3283: stderr: [Full GC 2106845K->1215242K(2784880K), 30.4016208 secs] 


xaa:1: [11/Oct/2011:16:00:28] WARNING (17125): CORE3283: stderr: [Full GC 3114936K->2985477K(3114944K), 53.0468651 secs] --> garbage collection occurring too often as noticed in the time. garbage being collected is quite low and if you would notice is quite close the the heap size. during the 53 seconds, this is equivalent to a pause. 
xaa:2087: [11/Oct/2011:16:01:35] WARNING (17125): CORE3283: stderr: [Full GC 3114943K->2991338K(3114944K), 58.3776291 secs] 
xaa:3897: [11/Oct/2011:16:02:33] WARNING (17125): CORE3283: stderr: [Full GC 3114940K->2997077K(3114944K), 55.3197974 secs] 
xaa:5597: [11/Oct/2011:16:03:00] WARNING (17125): CORE3283: stderr: [Full GC[Unloading class sun.reflect.GeneratedConstructorAccessor119] 
xaa:7936: [11/Oct/2011:16:04:36] WARNING (17125): CORE3283: stderr: [Full GC 3114938K->3004947K(3114944K), 55.5269911 secs] 
xaa:9070: [11/Oct/2011:16:05:53] WARNING (17125): CORE3283: stderr: [Full GC 3114937K->3012793K(3114944K), 70.6993328 secs] 

Answer 1

Dal momento che hai pause GC extremenly lungo, è non pensare che cambiare algoritmo GC aiuterebbe.

Si noti che è altamente sospetto che si abbiano solo raccolte complete. Forse è necessario aumentare le dimensioni della giovane generazione e/o dello spazio sopravvissuto.

Consulta anche:

• Tuning Garbage Collection with the 1.4.2 Java[tm] Virtual Machine

Answer 2

tuo mucchio è troppo piccolo. La pausa è così grande perché è impegnata a scansionare ripetutamente l'intero heap alla disperata ricerca di qualcosa da collezionare.

È necessario eseguire 1 o possibilmente più di quanto segue;

• trovare e correggere una perdita di memoria
• sintonizzare l'applicazione per utilizzare meno memoria
• configurare la JVM è utilizzare un mucchio grande

sei legato a 1.4.2 per qualche motivo? Le implementazioni GC sono davvero passate da allora, quindi dovresti prendere in considerazione l'aggiornamento, se possibile. Mi rendo conto che questa potrebbe essere un'impresa non banale, ma vale la pena considerare comunque.

Answer 3

Se si dispone di un alto tasso di sopravvivenza, l'heap potrebbe essere troppo grande. Più grande è l'heap, più a lungo la JVM può andare senza GC, quindi una volta colpito, ha molto più da muoversi.

Answer 4

Fase 1:

1. Assicurarsi di aver impostato memoria sufficiente per l'applicazione.
2. Assicurarsi di non avere perdite di memoria nell'applicazione. Eclipse Memory Analyzer Tool o visualvm ti aiuteranno a identificare le perdite nella tua applicazione.

Fase 2:

Se non avete problemi con il passaggio 1 per quanto riguarda le perdite di memoria, consultare la documentazione di Oracle page su casi di utilizzo per l'algoritmo di raccolta specifica dei rifiuti in "Garbage Collectors Java "articolo e articolo gctuning.

Dato che si è deciso di configurare heap più grandi (> = 8 GB), G1GC dovrebbe funzionare correttamente. Fare riferimento a questa connessa interrogazione SE su parametri chiave di affinamento:

Java 7 (JDK 7) garbage collection and documentation on G1