2016-03-31 27 views
6

Wenn G1 beschließt, gemischte Sammlungen zu erstellen, schrumpft es unseren Eden-Raum aggressiv von 10 g auf etwa 1 g.Warum verkleinert G1GC die junge Generation, bevor sie gemischte Sammlungen startet?

{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 

Dies ist, nachdem es mit 10-11g Eden für 60 oder mehr Sammlungen läuft.

Hier werden die entsprechenden JVM GC-Parameter sind mit wir laufen

-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" 

Nach page 55 of this presentation, muss er Eden, um die Größe, so dass max Pause Ziel für den gesamten Haufen ausmacht, nicht nur auf die neue Generation. Warum ist der Sammler so aggressiv?

Durchschnittliche Pausenzeiten für junge Generationen liegen zwischen 50-150 ms bei einer Größe von 10 g. Wenn die Präsentation korrekt ist (ich habe nichts anderes gefunden, um die Aussage zu unterstützen), würde ich erwarten, dass sie um die Hälfte schrumpft (20g Heap), nicht 10x.

+0

Ich habe gerade diese Präsentation gelesen (es ist wirklich ziemlich gut), aber ich sehe nicht die gleichen Dinge auf Folie 55, die Sie in Ihrem Beitrag erwähnen. Und es zeigt ein Beispiel von eden, das von 12,5 gb auf <1 gb reduziert wird, was Ihrem ähnlich ist. Können Sie genauer erklären, warum Sie erwarten, dass eden weniger schrumpft als es hat? –

+0

Und, vielleicht in Betracht ziehen, das Print-adaptive-Size-Policy-Flag hinzuzufügen. –

+0

@EngineerDollery Der Parameter 'PrintAdaptiveSizePolicy' ist aktiviert (zur Frage hinzugefügt). In der Präsentation, Ausgabe # 3, heißt es: "Muss alte Regionen berücksichtigen, nicht nur junge, derzeit schrumpft G1 die junge Generation". Im Idealfall würde ich nicht erwarten, dass die Generation schrumpft. Wir haben unser Pausenziel auf 1000 ms festgelegt, und Sammlungen sind viel schneller. Den doppelten Müll (der bereits markiert ist) zu sammeln, sollte nicht mehr als die doppelte Zeit dauern. – Savior

Antwort

5

Sie können keine Antwort für Ihre Anfrage in Rutsche: 56

Junge Generation um den Faktor 20x

geschrumpft

So durch eine Fabrik 10fach Schrumpfung ist keine Überraschung.

Von infoQ Artikel von Monica Beckwith auf Tipps für Tuning G1GC:

Der vollständige GC, indem man den Kindergarten/junge gen schrumpfen auf den Standardmindest (5% des gesamten Java Heap) hätte vermieden werden können

Da Sie nicht junge gen Größe explizit festgelegt haben, ist Standardwert

-XX:G1NewSizePercent=5 

die percentag Sets e des Heaps als Mindestgröße für die junge Generation zu verwenden.

So Ihre Pausenzeit Ziel

-XX:MaxGCPauseMillis=1000 

die junge Generation kann bis zu 5% des gesamten Heap schrumpfen zu respektieren.

Ich habe eine gute Google-Gruppe Artikel über G1GC bei https://groups.google.com/a/jclarity.com/forum/#!msg/friends/hsZiz6HTm9M/klrRjBclCwAJ

Wenn G1 vorhergesagt Pausenzeit Ziel ist es größer als das Soll-Pausenzeit Ziel, dann schrumpft junge Generation, aber nicht mehr als G1NewSizePercent der gefunden aktuelle Java-Heap-Größe (nicht die maximale Größe). Auch hier wird der gesamte Java-Heap basierend auf dem berechneten GC-Zeitverhältnis gegenüber dem Wert GCTimeRatio wachsen (oder schrumpfen).

Hinweis: G1NewSizePercent und G1MaxNewSizePercent sind nicht mit NewSize oder MaxNewSize verwechselt werden.

G1NewSizePercent und G1MaxNewSizePercent legte eine untere und obere Schranke jeweils an, wie klein oder wie groß junge Generation kann durch G1 dimensioniert werden.

Auf einer anderen Note, haben Sie viele Parameter konfiguriert, die Sinus-un-nötig sein kann G1GC wenn die meisten der Standardparameter gut funktioniert haben, auf die Standardwerte gesetzt. Weitere Einzelheiten finden Sie in dieser SE-Frage.

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

Zusammengefasst: Je nach Pausenzeit Ziel wird jung gen schrumpfen. Wenn Sie sich wirklich Sorgen machen, dass junge Gene auf einen niedrigen Wert schrumpfen, konfigurieren Sie -XX:G1NewSizePercent. Aber ich werde es nicht so lange empfehlen als -XX:MaxGCPauseMillis erfüllt ist

EDIT:

Von G1GC ergonomics Seite

Es ist typisch, dass die Größe des Haufens schwingt als Der Müllsammler versucht konkurrierende Ziele zu erreichen. Dies gilt auch, wenn die Anwendung einen stabilen Zustand erreicht hat. Der Druck, ein Durchsatzziel zu erreichen (was einen größeren Heap erfordern kann) konkurriert mit den Zielen für eine maximale Pausenzeit und einen minimalen Footprint (was beide einen kleinen Heap erfordern können).

+0

So Ihrer Antwort ist es, weil es kann? Das befriedigt mich nicht und Sie haben es derzeit nicht mit irgendwelchen Unterlagen unterstützt. Wie ich anhand der gedruckten GC-Details gezeigt habe, liegt die Pausenzeit bereits innerhalb des Ziels der maximalen Pausenzeit. Es gibt keinen Grund, die Größe so zu ändern. Eine so große Größe verursacht eine größere Belastung für die Anwendung. Gegenwärtig kann diese Anwendung 10 g Müll in 2-3 Sekunden erzeugen. Mit einem neuen 800m-Heap wird die JVM alle paar hundert Millisekunden starten. Dies wirkt sich negativ auf den Durchsatz aus. – Savior

+0

Von der Orakeldokumentationsseite: Der G1 GC hat ein Pausenzeitziel, das er zu erreichen versucht (weiche Echtzeit).In jungen Kollektionen passt der G1 GC seine junge Generation (Eden- und Survivor-Größen) an das weiche Echtzeitziel an. Bei gemischten Sammlungen passt der G1-GC die Anzahl der alten Regionen an, die basierend auf einer Zielanzahl gemischter Speicherbereinigungen, dem Prozentsatz an Live-Objekten in jeder Region des Heapspeichers und dem insgesamt akzeptablen Haufenabfallanteil gesammelt werden. –

+0

Dieser Artikel und Info Artikel sind Beweis. –