Java-Optimierung Grundlagen, Konfiguration, Methoden und Werkzeuge zur Optimierung von Oracle-Java - Vesperbox am Freitag, den 09.11.2012
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Java-Optimierung
Grundlagen, Konfiguration, Methoden und Werkzeuge zur
Optimierung von Oracle-Java
Vesperbox am Freitag, den 09.11.2012
Daniel Bäurer
inovex GmbH
Systems Engineer
Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und uns selbst.Inhalt
● Grundlagen der Speicherverwaltung von Oracle-Java
● Garbage-Collection und GC-Algorithmen
● Konfiguration des Speichers und des Garbage-Collector
● Methoden zur Optimierung von Oracle-Java
● Werkzeuge zur Optimierung von Oracle-Java
● Weiterführende Referenzen
04.12.12Grundlagen der Speicherverwaltung von Oracle-Java
Oracle-Java allokiert zwei Bereiche im Hauptspeicher:
● Perm-Generation – Speicherbereich, in dem Klassen, Methoden
sowie nativ kompilierte Objekte vorgehalten werden, die während
der gesamten Laufzeit der JVM vorhanden sind.
● Heap – Speicherbereich, in dem zur Laufzeit der JVM dynamisch
Objekte erzeugt, vorgehalten und entfernt werden.
● Der Heap ist weiterhin in zwei Unterbereiche aufgeteilt. Den
sogenannten Young- und Old-Generation (auch als Tenured
bezeichnet), in denen sich Objekte unterschiedlichen Alters
befinden.
● Auch der der Young-Gen wird in Unterbereichen organisiert. Diese
werden als Eden, Survivor 1 und Survivor 2 bezeichnet.
04.12.12Grundlagen der Speicherverwaltung von Oracle-Java
Quelle: http://misnad.wordpress.com/2012/03/01/jvm-heap-garbage-collection-volume-1/
● Neue Objekte werden immer (bis auf wenige Ausnahmen) in Eden
erzeugt.
● Dynamisch erzeugte Objekte können erreichbar (leben) oder nicht
mehr erreichbar (tot) sein.
04.12.12Grundlagen der Speicherverwaltung von Oracle-Java
● Sobald Eden voll ist, werden alle lebenden Objekte in den aktiven
Survivor (To genannt) kopiert und alle toten Objekte entfernt.
● Ebenfalls werden alle lebenden Objekte des inaktiven Survivor
(From genannt) in den aktiven Survivor kopiert und alle toten
Objekte entfernt.
● Beide Survivor-Bereiche tauschen fortwährend ihre Rolle.
● Objekte die ein gewisses Alter (Kopiervorgänge) erreichen, werden
in den Old-Generation (Tenured) kopiert.
● Sobald auch Tenured gefüllt ist, bzw. Eden und den aktiven
Survivor nicht mehr aufnehmen kann, müssen auch dort alle toten
Objekte entfernt werden.
04.12.12Grundlagen der Speicherverwaltung von Oracle-Java
Quelle: http://misnad.wordpress.com/2012/03/01/jvm-heap-garbage-collection-volume-1/
● Aufräumarbeiten in Young-Generation werden als Minor-GC
bezeichnet.
● Aufräumarbeiten in Old-Generation werden als Major-GC
bezeichnet.
04.12.12Garbage-Collection und GC-Algorithmen
● Im Gegensatz zu manch anderer Programmiersprache, muss sich
bei Java nicht der Programmierer um die Speicherreservierung
oder -freigabe kümmern.
● Java verwendet zur automatischen Freigabe des Speichers die,
bereits angesprochene, Garbage-Collection (GC).
● Für eine Garbage-Collection muss die Anwendung gestoppt
werden.
● Eine Garbage-Collection beansprucht CPU-Threads, bzw.
Prozessorzeit.
04.12.12Garbage-Collection und GC-Algorithmen
Minor-GC
Thread belegt durch die GC
Thread belegt durch die
Applikation
Serial Collector Parallel Collector Major-GC
Mark Sweep Compact
Serial Mark, Parallel
Mark-Sweep-Compact Collector (MSC) Sweep, Compact Compact
Initial Mark
Concurrent Mark
Remark
Concurrent Mark and Sweep Collector (CMS)
Concurrent Sweep
04.12.12Garbage-Collection und GC-Algorithmen
● Das Aufräumen der Young-Generation wird durch kopieren
erreicht.
● Das Aufräumen der Old-Generation wird durch Reorganisation
erreicht, was wesentlich aufwändiger ist.
● Da die Old-Generation im Vergleich zur New-Generation relativ
groß ist, dauert ein Major-GC länger.
● Der CMS-Algorithmus fragmentiert den Speicher und falls die
Fragmentierung zu stark ist, wird Mark-Sweep-Compact
ausgeführt.
● Ebenfalls muss der CMS-Algorithmus rechtzeitig anlaufen um für
den nächsten Minor-GC Platz zu schaffen, was einen gewissen
Zuschlag für Tenured (bis zu 30%) erfordert. Allerdings kann CMS
den GC-Lauf mit der Minor-GC koordinieren.
● Ausblick: Garbage-First GC (G1)
04.12.12Konfiguration des Speichers und des Garbage-Collector
● Die Speichergröße die Young- und Old-Generation (Heap) belegen
dürfen, wird mit den Parametern Xms (Minimum) und Xmx
(Maximum) angegeben.
● Die Speichergröße des Young-Generation (Eden, Survivor 1,
Survivor 2) wird mit den beiden Schaltern NewSize und
MaxNewSize eingestellt.
● Die Größe von Eden und eines Survivor (Survivor 1 = Survivor 2)
kann man nur über die Angabe des SurvivorRatio einstellen:
SurvivorRatio MaxNewSize
Eden= ∗MaxNewSize Survivor =
SurvivorRatio+2 SurvivorRatio+ 2
● Auch die Größe von Tenured (Old-Generation) ergibt sich nur
indirekt:
Tenured =Xmx −MaxNewSize
● Die Größe der Perm-Generation kann man wieder direkt einstellen
und zwar mit den Schaltern PermSize (initiale Größe) und
MaxPermSize (maximale Größe)
04.12.12Konfiguration des Speichers und des Garbage-Collector
Quelle: http://misnad.wordpress.com/2012/03/01/jvm-heap-garbage-collection-volume-1/
Eden S1 S2
SurvivorRatio=2: Eden=2/4, S1=1/4, S2=1/4
Eden S1 S2
SurvivorRatio=8: Eden=8/10, S1=1/10, S2=1/10
04.12.12Konfiguration des Speichers und des Garbage-Collector
● Keine dynamische Größenanpassung des Speichers ermöglichen,
sondern immer Xms = Xmx, bzw. NewSize = MaxNewSize
konfigurieren.
● Bytegrößen können mit k (KB), m (MB), g (GB), t (TB) angegeben
werden, beispielsweise Xmx2g, MaxNewSize=512m.
● Ab wann Objekte soweit gealtert sind, dass sie aus dem Young-
Generation in den Old-Generation kopiert werden, wird mit dem
Schalter MaxTenuringThreshold eingestellt.
● Ein MaxTenuringThreshold von 10 bedeutet, dass ein Objekt 10
mal im Young-Generation kopiert werden kann, bevor es in
Tenured kopiert wird.
● Für eine bessere Unterstützung von Multiprozessormaschinen
kann „Non-Uniform Memory Access“ (UseNUMA) sowie „Thread-
local allocation Buffer“ (UseTLAB) verwendet werden.
04.12.12Konfiguration des Speichers und des Garbage-Collector
● Der Serielle-Garbage-Collector (UseSerialGC) dürfte dank
moderner CPU-Technik vermutlich nur noch für Client-
Anwendungen Verwendung finden.
● Mit UseParallelGC wird der parallele Garbage-Collector gewählt,
der für das bereinigen des Young-Generation verantwortlich ist.
● Sofern man den CMS-GC verwendet, sollte man als parallelen
Garbage-Collector den UseParNewGC verwenden. Dieser kann
mit dem CMS-GC interagieren und so gemeinsame GC-Läufe
koordinieren.
● Wichtig bei der Benutzung der parallelen GC-Algorithmen ist, dass
die Threadanzahl, die verwendet werden soll, explizit mittels des
Schalters ParallelGCThreads eingestellt wird.
04.12.12Konfiguration des Speichers und des Garbage-Collector
● Das parallele Compacting des Mark-Sweep-Compact Garbage-
Collector wird mit dem Schalter UseParallelOldGC aktiviert. Für
die maximale Anzahl der GC-Threads wird der Wert von
ParallelGCThreads verwendet.
● Um den CMS-GC zu aktivieren, wird der Schalter
UseConcMarkSweepGC benutzt. Der CMS-GC besitzt einen
eigenen Schalter für die maximal zu verwendenden Threads,
ParallelCMSThreads.
● Das parallele Remarking des CMS sollte ebenfalls explizit aktiviert
werden, CMSParallelRemarkEnabled.
● Um manuelle ausgelöste Garbage-Collector-Läufe zu unterbinden,
sollten diese explizit mit dem Schalter DisableExplicitGC nicht
ermöglicht werden.
04.12.12Methoden zur Optimierung von Oracle-Java
● Um Oracle-Java vernünftig optimieren zu können, müssen zu
Beginn eine Reihe von Logging-Paramtern aktiviert werden, um
aussagekräftige Messwerte zu erhalten.
verbose:gc
PrintGC
PrintGCDetails
PrintHeapAtGC
PrintGCTimeStamps
PrintGCDateStamps
PrintGCApplicationStoppedTime
PrintGCApplicationConcurrentTime
PrintTenuringDistribution
● Neben den Messwerten, benötigt man für die Optimierung auch
eine realistische Last. Ohne diese ist eine Optimierung relativ
sinnlos!
● Das Vorgehen zur Optimierung sollte so gewählt werden, dass
jeder Funktionsbereich (Eden, Survivor, Tenured, Alterung, Minor-
GC, Major-GC) separat betrachtet wird.
04.12.12Methoden zur Optimierung von Oracle-Java
● Die Wahl des richtigen Garbage-Collector für die Minor-GC ist, wie
bereits angedeutet, aus Sicht heutiger Multiprozessor-Systeme
relativ einfach. Es sollte der parallele GC verwendet werden und
die Anzahl der zu verwendenden Threads ermittelt werden.
● Zur Bestimmung der Größe von Eden muss berücksichtigt werden:
● Desto größer Eden ist, desto weniger Minor-GCs finden statt.
● Desto mehr Objekte in Eden sterben, desto besser.
● Wie Altern die Objekte der Java-Anwendung?
● Bestimmen der Größe von Eden:
● Setze Eden sehr groß
Größe Eden
● Ermittle die Allokationsrate: Allokationsrate=
Intervall MinorGC
● Passe Eden an: Eden= Allokationsrate∗(Zielintervall MinorGC∗Reserve)
04.12.12Methoden zur Optimierung von Oracle-Java
● Bei der Optimierung des Survivor-Bereich sollte beachtet werden:
● Desto kleiner der Survivor-Bereich ist, desto eher werden
Objekte nach Tenured verschoben die nicht mehr lange leben.
● Bleiben langlebende Objekte zu lange im Survivor-Bereich,
werden diese unnötig oft kopiert.
● Bestimmung des Survivor-Bereichs:
● MaxTenuringThreshold sehr hoch einstellen.
● Erkennt man bei der Betrachtung der Altersverteilung, dass
Objekte mit der Zeit erheblich „ausaltern“ und ab einem
gewissen Alter nicht mehr so stark, dann ist dies der beste
Wert für MaxTenuringThreshold.
● Altern Objekte hingegen nicht merklich aus, dann kann man
MaxTenuringThreshold auf einen sehr kleinen Wert (2-3)
einstellen.
04.12.12Methoden zur Optimierung von Oracle-Java
Quelle: http://www.angelikalanger.com/Articles/EffectiveJava/49.GC.GenerationalGC/49.GC.GenerationalGC.html
● Zur Ermittlung des Survivor-Ratio macht man diesen zu Beginn
wieder recht groß und schaut welchen Füllgrad er über den Lauf
der Zeit im Schnitt annimmt.
● Mit dem so ermittelten Wert, kann man die Survivor-Größe indirekt
einstellen.
04.12.12Methoden zur Optimierung von Oracle-Java
● Für die Wahl des Garbage-Collector der Major-GC kann man den
Mark Sweep Compact benutzen, wenn
● relativ lange Pausenzeiten kein Problem ist.
● Tenured relativ klein ist.
● Probleme mit CMS auftreten.
● In den meisten Fällen dürfte die Wahl auf den CMS Garbage-
Collector fallen.
● Beim Mark-Sweep-Compact GC sollte paralleles Compact aktiviert
werden und bei CMS die Anzahl der parallelen Threads explizit
gesetzt werden.
● Es kann dennoch nicht schaden, beide Garbage-Collectoren
miteinander zu vergleichen.
04.12.12Methoden zur Optimierung von Oracle-Java
● Bei der Optimierung von Tenured sollte beachtet werden:
● Desto größer Tenured desto weniger Major-GC finden statt.
● Desto größer Tenured desto länger die Laufzeit der Major-GC.
● Ein zu kleiner Tenured führt zu häufigen Major-GCs.
● Desto mehr langlebige Objekte in Tenured betrachtet werden
müssen desto länger die Laufzeit der Major-GC.
● Bestimmung der Größe von Tenured:
● Die minimale Größe von Tenured ist direkt nach einem Major-
GC zu ermitteln.
● Ermittle das durchschnittliche Volumen das bei einer Minor-GC
aus der Young-Generation nach Tenured kopiert wird.
● Nun kann man anhand eines Zielintervalls der Major-GC die
benötigte Tenured-Größe bestimmen:
MajorGC Zielintervall
Tenured = ∗∅ Volumen MinorGC
MinorGC Intervall
04.12.12Methoden zur Optimierung von Oracle-Java
● Die Speichergröße der Perm-Generation ist relativ statisch.
● Um die Größe der benötigten MaxPermSize zu ermitteln, stellt man
diese recht große ein und betrachtet sie über einen längeren
Zeitraum.
● Hier wird sich im laufe der Zeit eine Sättigung einstellen, welche
als Größe für MaxPermSize (+Puffer) verwendet werden kann.
04.12.12Werkzeuge zur Optimierung von Oracle-Java
● Loglevel hoch drehen
● Logdatei betrachten
● Auswertung mit Scripten
● GCViewer https://github.com/chewiebug/GCViewer/wiki/Changelog
● PsiProbe https://code.google.com/p/psi-probe/downloads/list
04.12.12Weiterführende Referenzen
● Oracle-JVM-Options:
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
● Tuning-Guide von Oracle:
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
04.12.12Vielen Dank für Ihre Aufmerksamkeit!
inovex GmbH
Pforzheim München Köln
Karlsruher Straße 71 Valentin-Linhof-Straße 2 Schanzenstraße 6-20
D-75179 Pforzheim D-81829 München D-51063 Köln
04.12.12Sie können auch lesen
