Ich rüste meine Produktionshardware auf, und wir sehen viel mehr Young-Gen GCing auf dem neuen Satz von Ausrüstung im Vergleich zu den alten.
Auf beiden Rechnern läuft das gleiche Programm (identische Binaries). Ein offensichtlicher Unterschied (ich hoffe, dass dies für die JVM keinen Unterschied macht) ist, dass wir RHEL5 - & gt; RHEL6.
Unsere JVM (Java 64-Bit Hotspot 1.6, gleiche java -version für beide) läuft mit denselben Befehlszeilen-GC-Optionen:
Auch:
%Vor% Der Unterschied zwischen den Maschinen besteht darin, dass die neue Box ungefähr doppelt so viel RAM ( 32gb - obwohl der maximale Heap unverändert ist) und einige weitere Kerne (24 vs. 16) hat.
Die Anwendung selbst verbindet sich mit mehreren externen Prozessen und führt viele Netzwerkoperationen aus - daher könnte auf eine Regression, Fehlkonfiguration oder Inkompatibilität hinweisen (deshalb testen wir ...). Was ich gerne wissen möchte ist:
Ist eine erhöhte Anzahl von GCs für junge Menschen wahrscheinlich eine natürliche und erwartete Folge von mehr Kernen, oder sollte ich über diese Entwicklung besorgt sein?
Wir haben die Anzahl der GCs in JConsole bestätigt, aber das ist in etwa so:
%Vor% (Anmerkung -XX:+PrintGC -XX:+PrintGCDetails )
Vollständige GCs sehen auf beiden Feldern gleich aus.
Beachten Sie, dass dies die Anzahl der GCs im Verlauf des gesamten Anwendungsstartprozesses ist - es führt also nicht "mehr Arbeit" aus. Es ist die gleiche Arbeit, mit mehr GC-Läufen.
Ich fragte mich zum Beispiel, ob -XX:+UseParallelGC zu viel mehr Einträgen im Protokoll führen würde, weil mehr Threads verwendet wurden (die jungen Gen-Sammlungen in kleinere Stücke zerlegen, also mehr, kleinere Sammlungen - nichts, was zu sein wäre) besorgt über).
Rätselhafte Frage ...
Kurze Antwort
Nein, die GC-Frequenz ist nur eine Funktion Ihrer Erzeugungsrate. Sofern Ihre Anwendung diese neue Hardware nicht nutzt, sollte die GC-Frequenz identisch sein.
Lange Antwort
Ich glaube nicht, dass es mit dem OS-Upgrade zusammenhängt, noch glaube ich, dass die Erhöhung des Gesamt-RAM etwas damit zu tun hat.
Es kann nicht von einer Erhöhung der Zeigergröße kommen, da die maximale Größe des Heapspeichers 1 GB beträgt. Daher verwendet die JVM bereits 32-Bit-Zeiger, selbst wenn Sie sich in einer 64-Bit-JVM befinden.
Verwendet Ihre Anwendung beim Start alle Kerne?
Es könnte den Anstieg der YoungGC-Raten erklären: Wenn Ihre Anwendung 8 weitere Threads verwendet, bedeutet dies, dass sie mehr Arbeit für die gleiche Zeit ausführt. Sie sollten eine Erhöhung der Zuweisungsrate beobachten (siehe Ihre GC-Protokolle).
Sie sollten auch eine Abnahme der Young-GC-Dauer bemerken, da PSScavenge mehr Threads verwendet. Ist das korrekt?
Laut dieser Seite , ParallelGCThreads = (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8) . Sie haben 13 Threads für einen YGC-Zyklus verwendet und verwenden jetzt 18.
Es hängt von Ihrer OS-Architektur ab (x64 oder x86) mit einem x86 geht der jvm bis zu 4Gb mit einem x64 geht es bis 2Gb (RAM ammount).
Tags und Links java garbage-collection jvm