Option 1: Verwenden Sie den Standardkollektor "throughput/parallel scavenge", wenn
die integrierte Optimierung aktiviert ist.
Ab Version 5 unterstützt die Sun-HotSPot-JVM bis zu einem gewissen Grad die Erkennung des Betriebssystems, unter dem der Server
ausgeführt wird. Die JVM versucht, den geeigneten Modus für die Garbage-Collection nach Objektalter
zu konfigurieren, der in Abhängigkeit davon, ob mehrere Prozessoren vorhanden sind und wie groß der physischer Hauptspeicher ist, parallel oder seriell sein kann.
Es wird erwartet, dass alle Hardwarekomponenten, unter denen das Produkt im Produktions- und Vorproduktionsmodus ausgeführt wird,
die Anforderungen für eine Serverklassenmaschine erfüllt.
Einige Hardwarekomponenten, die in Entwicklungsumgebungen eingesetzt werden, erfüllen diese Kriterien unter Umständen nicht.
Das Verhalten des Durchsatzkollektors, ob automatisch optimiert oder nicht, bleibt immer dasselbe.
Es entstehen während der Ausführung des Java-Anwendungssystems erhebliche Pausen, die sich proportional zur Größe des genutzten Heapspeichers verhalten,
wenn der Collector versucht, die Vorteile der Garbage-Collection nach Objektalter
zu maximieren.
Diese automatischen Algorithmen können bestimmen, ob sich Ihre Workload für die Aktionen dieser Algorithmen gut eignen oder ob eine andere
Garbage-Collection-Strategie für Ihr System erforderlich bzw. besser geeignet ist.
Sehen Sie sich die folgenden Optimierungsparameter an:
- -XX:+UseParallelGC
- -XX:+UseAdaptiveSizePolicy
- -XX:+AggressiveHeap
Option 2: Verwenden Sie den Standardkollektor "throughput/parallel scavenge", aber optimieren Sie ihn manuell.
Die Verwendung des integrierten Algorithmus, der mit dem Parameter
"-XX:+UseAdaptiveSizePolicy" konfiguriert wird, hat unter anderem den Nachteil, dass die Konfigurationsmöglichkeiten
anderer Parameter, wie z. B. die des Parameters "-XX:SurvivorRatio", beschränkt sind, wenn der integrierte
Algorithmus verwendet wird. Wenn Sie den integrierten Algorithmus verwenden, müssen Sie einen Teil der Steuerung
der Ressourcenzuordnungen während der Ausführung aus der Hand geben.
Wenn die Ergebnisse des integrierten Algorithmus nicht zufriedenstellend sind, ist es einfacher, die JMS-Ressourcen
zu konfigurieren, als zu versuchen, die Aktionen des Algorithmus zu optimieren.
Bei der manuellen Konfiguration der JVM-Ressourcen müssen nur halb so viele Optionen verwendet werden wie bei der
Optimierung der Aktionen des Algorithmus.
Sehen Sie sich die folgenden Optimierungsparameter an:
- -XX:NewRatio=2: Dies ist die Standardeinstellung für einen Server, der für den VM-Modus konfiguriert ist.
- -XX:MaxNewSize= und -XX:NewSize=
- -XX:SurvivorRatio=
- -XX:+PrintTenuringDistribution
- -XX:TargetSurvivorRatio=
Option 3: Verwenden Sie den "concurrent low-pause mark-sweep"-KollektorDieser Kollektor
ist ein radikaler Abschied von der Weiterentwicklung der Garbage-Collection nach Objektalter, die unter der
Hotspot-Architektur festgelegt wurde, weil er eine Überlappung von Anwendungsthreadverarbeitung und
im Hintergrund ausgeführten Garbage-Collection-Threads mit dedizierter niedriger Priorität erlaubt. Wenn Ihre
Anwendungsdaten mit dem Verhalten des Standarddurchsatzkollektors nicht kompatibel sind, kann der
"concurrent mark-sweep"-Collector (CMS) eine praktikable Strategie sein, insbesondere für Anwendungssysteme, die keine
invasiven Pausen tolerieren.
Dieser Collector ist insbesondere bei sehr großen Heapspeichern, die für die
64-Bit-JVM verwendet werden, oder bei Anwendungen mit sehr vielen
Daten mit langer Lebensdauer (auch große permanente Generation genannt) hilfreich und
lieferte eine vergleichsweise gute Cacheauslastung, indem Young-Generation-Seiten zum großen Teil
beibehalten werden, selbst wenn der Hintergrundthread alle Seiten des gesamten Heapspeichers scannen muss.
Wenn Sie den CMS-Collector prinzipell als Housekeeping-Agenten verwenden möchten, fügen Sie diese Option an Stelle
der anderen Garbage-Collection-Modi Ihrer JVM-Konfiguration hinzu.
Sehen Sie sich die folgenden Optimierungsparameter an:
- -XX:+UseConcMarkSweepGC
- -XX:CMSInitiatingOccupancyFraction=75
- -XX:SurvivorRatio=6
- -XX:MaxTenuringThreshold=8
- -XX:NewSize=128m
Eine der Schwierigkeiten bei der Optimierung mit
CMS ist die, dass die Garbage-Collection im schlimmsten Fall, nämlich beim Abbruch des
CMS-Zyklus, mehrere Sekunden dauern kann, was insbesondere auf Systemen Kosten verursacht, die
CMS genau deshalb einsetzen, um lange Pausen zu verhindern. Service-Level-Agreements können die Verwendung von CMS vorschreiben,
weil beim Einsatz von CMS die durchschnittlichen Pausenzeiten sehr, sehr gering sind. Die Optimierung muss
so durchgeführt werden, dass die CMS-Zyklen auf keinen Fall unterbrochen werden.
CMS ist nur erfolgreich, wenn der vorausschauende CMS-Trigger sicherstellt, dass der
CMS-Zyklus früh genug gestartet wird, damit stets ausreichend freie Ressourcen verfügbar sind, bevor diese angefordert werden.
Wenn der CMS-Kollektor nicht abgeschlossen werden kann, bevor sich die Region mit den älteren Objekten füllt,
wird die Collection durchgeführt, indem die Anwendungsthreads angehalten werden. Dies wird als vollständige
Gargabe-Collection bezeichnet.
Vollständige Garbage-Collections sind ein Hinweis darauf, dass eine weitere Optimierung erforderlich ist, damit
der Collection seine Operationen besser an Ihre Anwendung anpassen kann.
Letztlich
erhöht CMS anders als andere Garbage-Collection-Modi mit Komprimierungsphase
theoretisch das Risiko einer Fragmentierung mit der HotSpot-JVM. In der Praxis tritt dieses Problem jedoch nur
selten auf, während die Garbarge-Collection einen beträchtlichen Teil des Heapspeichers wiederherstellt.
In den Fällen, in denen CMS ausfällt oder eine Collection abbricht, wird eine alternative
Garbage-Collection mit Komprimierung ausgelöst. Zwangsläufig bringt jeder andere Typ von Garbage-Collection im Vergleich mit einer
normalen CMS-Collection erhebliche invasive Pausen mit sich.
Fehler vermeiden: Wie beim Durchsatzkollektor stehen wesentlich mehr Optionen für eine explizite Steuerung von CMS
zur Verfügung.
Die beschriebenen Optionen sind jedoch die Basisoptionen, die bei der Optimierung der HotSpot-JVM wahrscheinlich auf jeden Fall berücksichtigen müssen.
gotcha