2016-03-31 20 views
6

Quando G1 decide di iniziare a creare raccolte miste, riduce il nostro spazio Eden da 10g a circa 1g.Perché G1GC riduce le giovani generazioni prima di avviare raccolte miste?

{Heap before GC invocations=294 (full 0): 
garbage-first heap total 20480000K, used 18304860K [0x00000002de000000, 0x00000002de804e20, 0x00000007c0000000) 
    region size 8192K, 1363 young (11165696K), 11 survivors (90112K) 
Metaspace  used 37327K, capacity 37826K, committed 38096K, reserved 1083392K 
    class space used 3935K, capacity 4081K, committed 4096K, reserved 1048576K 
2016-03-31T20:57:31.002+0000: 7196.427: [GC pause (G1 Evacuation Pause) (young) 
Desired survivor size 717225984 bytes, new threshold 1 (max 1) 
- age 1: 41346816 bytes, 41346816 total 
7196.427: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 144693, predicted base time: 48.88 ms, remaining time: 951.12 ms, target pause time: 1000.00 ms] 
7196.427: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 1352 regions, survivors: 11 regions, predicted young region time: 20.72 ms] 
7196.427: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 1352 regions, survivors: 11 regions, old: 0 regions, predicted pause time: 69.60 ms, target pause time: 1000.00 ms] 
7196.494: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: candidate old regions available, candidate old regions: 789 regions, reclaimable: 4703761904 bytes (22.43 %), threshold: 5.00 %] 
, 0.0673540 secs] 
    [Parallel Time: 60.1 ms, GC Workers: 18] 
     [GC Worker Start (ms): Min: 7196427.8, Avg: 7196428.1, Max: 7196428.2, Diff: 0.4] 
     [Ext Root Scanning (ms): Min: 7.3, Avg: 7.5, Max: 7.7, Diff: 0.4, Sum: 134.2] 
     [Update RS (ms): Min: 28.2, Avg: 28.8, Max: 29.9, Diff: 1.7, Sum: 518.4] 
     [Processed Buffers: Min: 41, Avg: 57.7, Max: 80, Diff: 39, Sum: 1039] 
     [Scan RS (ms): Min: 0.1, Avg: 0.2, Max: 0.5, Diff: 0.4, Sum: 3.7] 
     [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1] 
     [Object Copy (ms): Min: 22.1, Avg: 23.1, Max: 23.4, Diff: 1.3, Sum: 416.2] 
     [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1] 
     [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 18] 
     [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 2.5] 
     [GC Worker Total (ms): Min: 59.5, Avg: 59.7, Max: 60.0, Diff: 0.5, Sum: 1075.1] 
     [GC Worker End (ms): Min: 7196487.7, Avg: 7196487.8, Max: 7196487.9, Diff: 0.2] 
    [Code Root Fixup: 0.2 ms] 
    [Code Root Purge: 0.0 ms] 
    [Clear CT: 1.9 ms] 
    [Other: 5.2 ms] 
     [Choose CSet: 0.0 ms] 
     [Ref Proc: 0.5 ms] 
     [Ref Enq: 0.0 ms] 
     [Redirty Cards: 0.5 ms] 
     [Humongous Register: 0.2 ms] 
     [Humongous Reclaim: 0.1 ms] 
     [Free CSet: 2.3 ms] 
    [Eden: 10.6G(10.6G)->0.0B(848.0M) Survivors: 88.0M->152.0M Heap: 17.5G(19.5G)->7128.3M(19.5G)] 
Heap after GC invocations=295 (full 0): 
garbage-first heap total 20480000K, used 7299344K [0x00000002de000000, 0x00000002de804e20, 0x00000007c0000000) 
    region size 8192K, 19 young (155648K), 19 survivors (155648K) 
Metaspace  used 37327K, capacity 37826K, committed 38096K, reserved 1083392K 
    class space used 3935K, capacity 4081K, committed 4096K, reserved 1048576K 
} 
[Times: user=1.09 sys=0.00, real=0.07 secs] 
2016-03-31T20:57:31.070+0000: 7196.495: Total time for which application threads were stopped: 0.0699324 seconds, Stopping threads took: 0.0003462 seconds 

Questo è dopo che è stato in esecuzione con 10-11g di Eden per 60 o più collezioni.

Qui ci sono i parametri JVM GC appropriati stiamo correndo con

-Xms20000m -Xmx20000m 
-XX:+UseG1GC 
-XX:G1RSetUpdatingPauseTimePercent=5 
-XX:MaxGCPauseMillis=1000 
-XX:GCTimeRatio=99 
-XX:InitiatingHeapOccupancyPercent=35 
-XX:MaxTenuringThreshold=1 
-XX:G1ConcRefinementThreads=6 
-XX:ConcGCThreads=18 
-XX:ParallelGCThreads=18 

-XX:+PrintGCDetails" 
-XX:+PrintGCDateStamps" 
-XX:+PrintHeapAtGC" 
-XX:+PrintTenuringDistribution" 
-XX:+PrintGCApplicationStoppedTime" 
-XX:+PrintPromotionFailure" 
-XX:+PrintAdaptiveSizePolicy" 

Secondo page 55 of this presentation, ha bisogno di ridimensionare in modo Eden spiega che l'obiettivo massimo di pausa per l'intero mucchio, non solo per la nuova generazione. Perché il collezionista è così aggressivo?

I tempi medi di pausa della nuova generazione sono compresi tra 50-150 ms per una dimensione heap di 10 g. Se la presentazione è corretta (non ho trovato nient'altro per supportare la dichiarazione), mi aspetterei di ridurre la metà (20 g di heap), non di 10 volte.

+0

Ho appena letto quella presentazione (è abbastanza buona), ma non vedo le stesse cose sulla diapositiva 55 che menzioni nel tuo post. E, mostra un esempio di eden che riduce da 12.5gb a <1gb, che è piuttosto simile al tuo. Puoi spiegare più in dettaglio perché ti aspetti che l'eden si riduca meno di quello che ha? –

+0

E, forse, si consideri l'aggiunta del flag print-adaptive-size-policy. –

+0

@EngineerDollery Il parametro 'PrintAdaptiveSizePolicy' è abilitato (aggiunto alla domanda). Nella presentazione, numero 3, si afferma "Deve tenere conto delle vecchie regioni, non solo dei giovani, Attualmente G1 riduce la giovane generazione". Idealmente, non mi aspetto che la generazione si riduca del tutto. Abbiamo impostato il nostro obiettivo di pausa su 1000 ms e le raccolte sono molto più veloci di così. Dover raccogliere il doppio della spazzatura (che è già segnata) non dovrebbe richiedere più del doppio del tempo. – Savior

risposta

5

È possibile trovare la risposta per la domanda in slitta n: 56

giovane generazione ridotta di un fattore pari a 20X

Così contrazione da una fabbrica di 10 volte non è una sorpresa.

Da infoQ articolo di Monica Beckwith su suggerimenti per la messa a punto G1GC:

Il GC completa avrebbe potuto essere evitato lasciando che la scuola materna/giovane gen ridurre al minimo predefinito (5% del mucchio totale Java)

Dal momento che non è stato impostato giovane dimensioni gen esplicitamente, il valore predefinito è

-XX:G1NewSizePercent=5 

Imposta il percentag e dell'heap da utilizzare come minimo per le dimensioni della giovane generazione.

Quindi Per quanto riguarda la pausa obiettivo ora

-XX:MaxGCPauseMillis=1000 

il giovane generazione può ridursi fino a 5% del totale mucchio.

ho trovato un articolo buon gruppo Google per quanto riguarda G1GC a https://groups.google.com/a/jclarity.com/forum/#!msg/friends/hsZiz6HTm9M/klrRjBclCwAJ

Se G1 predetto tempo di pausa obiettivo è più grande l'obiettivo tempo di pausa di destinazione, quindi ridursi giovani generazioni, ma non più di G1NewSizePercent del dimensione heap Java corrente, (non la dimensione massima). Di nuovo, l'heap Java complessivo crescerà (o si ridurrà) in base al rapporto temporale GC calcolato in base al valore di GCTimeRatio.

Nota: G1NewSizePercent, e G1MaxNewSizePercent sono da non confondere con newSize o MaxNewSize.

G1NewSizePercent e G1MaxNewSizePercent mettere un limite inferiore e superiore, rispettivamente, a quanto piccolo o quanto grande giovane generazione può essere dimensionato per G1.

Su una nota diversa, sono stati configurati molti parametri che potrebbero non essere necessari. Sine G1GC funziona correttamente se la maggior parte dei parametri predefiniti è stata impostata su valori predefiniti. Fare riferimento a questa domanda SE per ulteriori dettagli.

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

In sintesi: seconda in porta tempo di pausa, giovane generazione si ridurrà. Se sei davvero preoccupato per il restringimento del gen giovane a basso valore, configura -XX:G1NewSizePercent. Ma non vi consiglio il più a lungo -XX:MaxGCPauseMillis è stata soddisfatta

EDIT:

Da G1GC ergonomics pagina,

E 'normale che la dimensione del mucchio oscillerà come il garbage collector cerca di soddisfare gli obiettivi in ​​competizione. Questo è vero anche se l'applicazione ha raggiunto uno stato stazionario. La pressione per raggiungere un obiettivo di throughput (che può richiedere un heap più grande) compete con gli obiettivi per un tempo di pausa massimo e un ingombro minimo (che può richiedere entrambi un piccolo heap).

+0

Quindi la tua risposta è che lo fa perché può? Questo non mi soddisfa e al momento non lo hai supportato con alcuna documentazione. Come ho dimostrato dai dettagli GC stampati, il tempo di pausa è già ben all'interno dell'obiettivo del tempo di pausa massimo. Non c'è motivo di ridimensionare così tanto. Il ridimensionamento causa molto più tensioni sull'applicazione. Attualmente, questa applicazione può generare 10 g di rifiuti in 2-3 secondi. Con un nuovo heap di 800 m, la JVM sarà in streaming ogni poche centinaia di millisecondi. Ciò influisce negativamente sul throughput. – Savior

+0

Dalla pagina di documentazione di Oracle: G1 GC ha un tempo di pausa target che tenta di soddisfare (tempo reale in tempo reale).Durante le collezioni giovani, il G1 GC adatta la sua giovane generazione (taglia eden e survivor) per soddisfare il morbido obiettivo in tempo reale. Durante le raccolte miste, GC G1 regola il numero di vecchie regioni raccolte in base a un numero di destinazione di garbage collection misti, la percentuale di oggetti vivi in ​​ogni area dell'heap e la percentuale di spreco di heap accettabile complessiva. –

+0

Questo articolo e gli articoli di informazione sono una prova. –