Haufeneinstellungen
-Xmx3550m: Stellen Sie den maximalen Heap -Speicher von JVM auf 3550 m ein.
-Xms3550m: Stellen Sie den anfänglichen Heap -Speicher von JVM auf 3550 m ein. Dieser Wert kann genauso wie -xmx festgelegt werden, um jedes Mal, wenn die Müllsammlung abgeschlossen ist, den Reallocing -Speicher von JVM zu vermeiden.
-XSSS128K: Stellen Sie die Stapelgröße jedes Threads fest. Nach JDK5.0 beträgt jede Gewindestapelgröße 1 m, und zuvor beträgt jede Gewindestapelgröße 256K. Es sollte gemäß der erforderlichen Speichergröße des Anwendungs -Threads eingestellt werden. Im selben physischen Speicher kann die Reduzierung dieses Wertes mehr Threads erzeugen. Das Betriebssystem hat jedoch weiterhin eine Grenze für die Anzahl der Threads in einem Prozess und kann nicht unendlich erzeugt werden, wobei die Erfahrungwerte zwischen etwa 3000 bis 5000 liegen.
-Xmn2g: Setzen Sie die Größe der Heap Memory Young Generation auf 2G. Die gesamte Haufenspeichergröße = Größe der Jugendgenerierung + alte Generationsgröße + persistierende Erzeugungsgröße. Die dauerhafte Erzeugung ist im Allgemeinen in einer Größe von 64 m festgelegt. Nach der Erhöhung der jüngeren Erzeugung wird die Größe der älteren Generation verringert. Dieser Wert hat einen großen Einfluss auf die Systemleistung, und Sun empfiehlt die Konfiguration offiziell als 3/8 des gesamten Haufens.
-Xx: permSize = 256m: Setzen Sie den Anfangswert des Heap -Speichers persistierende Erzeugung auf 256 m. (Es scheint die Initialisierungsparameter von IDEs wie Sonnenfinsternis zu sein)
-Xx: MaxNewSize = Größe: Der maximale Wert, den das neu generierte Objekt den Speicher belegen kann.
-Xx: maxpermSize = 512 m: Setzen Sie den Maximalwert der persistenten Generation auf 512 m.
-Xx: NewRatio = 4: Setzen Sie das Verhältnis der Heap Memory Young Generation (einschließlich Eden und zwei Überlebendenregionen) zur alten Generation des Heap -Speichers (mit Ausnahme der persistierenden Generation). Wenn sie auf 4 gesetzt sind, beträgt das Verhältnis der jüngeren Generation zur älteren Generation 1: 4.
-Xx: Survivorratio = 4: Setzen Sie das Verhältnis des Edenbereichs zum Überlebendenbereich in der jungen Generation des Heap -Speichers. Auf 4 ist das Verhältnis zwischen zwei Überlebendengebieten (die junge Generation von JVM Heap Memory hat standardmäßig 2 Überlebendebereiche) und ein Eden -Bereich beträgt 2: 4, und ein Überlebendenbereich entspricht 1/6 der gesamten jungen Generation.
-Xx: MaxTeuringThreshold = 7: bedeutet, dass ein Objekt in ältere Menschen platziert wird, wenn es sich 7 -mal im Rettungsraum (Überlebenderbereich) bewegt und nicht recycelt wurde.
Wenn die Objekte der jungen Generation auf 0 gesetzt werden, gehen sie nicht durch den Survivor -Bereich und betreten direkt die alte Generation. Für weitere Anwendungen in der alten Generation kann dies die Effizienz verbessern.
Wenn dieser Wert auf einen größeren Wert eingestellt wird, wird das Objekt der jungen Generation mehrmals im Überlebendenbereich kopiert, was die Überlebenszeit des Objekts in der jungen Generation erhöhen und die Wahrscheinlichkeit erhöhen kann, dass das Objekt in der jungen Generation recycelt wird.
Recycler -Auswahl
JVM gibt drei Optionen: Serienkollektor, paralleler Kollektor und gleichzeitiger Sammler, aber der serielle Kollektor ist nur für kleine Datenvolumina geeignet. Die Auswahl ist daher hauptsächlich für parallelen Kollektor und gleichzeitiger Sammler.
Standardmäßig verwendete JDK5.0 schon einmal serielle Sammler. Wenn Sie andere Sammler verwenden möchten, müssen Sie beim Start entsprechende Parameter hinzufügen. Nach JDK5.0 wird der JVM intelligente Urteile basierend auf der aktuellen Systemkonfiguration fällen.
Seriensammler
-Xx:+useserialgc: Setzen Sie den Seriensammler
Parallelsammler (Durchsatzpriorität)
-Xx:+useParallelGC: Wählen Sie den Müllsammler als Parallelsammler aus. Diese Konfiguration gilt nur für jüngere Generationen. Das heißt, unter der obigen Konfiguration verwendet die jüngere Generation eine gleichzeitige Sammlung, während die ältere Generation immer noch die serielle Sammlung verwendet.
-Xx: ParallelgcThreads = 20: Konfigurieren Sie die Anzahl der Threads des Parallelkollektors, dh wie viele Fäden werden gleichzeitig Müll gesammelt. Dieser Wert ist am besten so konfiguriert, dass er der Anzahl der Prozessoren entspricht.
-Xx:+useParalleloldGC: Konfigurieren Sie die Müllsammlung der alten Generation auf parallele Sammlung. JDK6.0 unterstützt die parallele Sammlung für ältere Generationen.
-Xx: maxgcpausemillis = 100: legt die maximale Zeit (in Millisekunden) für jede Müllsammlung der jungen Generation fest. Wenn diese Zeit nicht erfüllt werden kann, passt der JVM die Größe der jungen Generation automatisch an diesen Wert an.
-Xx:+UseadaptiveSizepolicy: Nach der Einstellung dieser Option wählt der Parallelkollektor automatisch die Größe des Bereichs der jungen Generation und das entsprechende Verhältnis von Überlebenden aus, um die vom Zielsystem angegebene minimale Reaktionszeit oder Sammelfrequenz zu erreichen.
Es wird empfohlen, dass dieser Parameter bei der Verwendung des Parallelsammlers eingeschaltet werden.
Gleichzeitiger Sammler (Reaktionszeit wird bevorzugt)
-XX:+UseParnewgc: Setzen Sie die junge Generation auf die gleichzeitige Sammlung. Kann gleichzeitig mit der CMS -Sammlung verwendet werden. JDK5.0 oder höher, der JVM wird es selbst gemäß der Systemkonfiguration festlegen, sodass dieser Wert nicht erneut festgelegt werden muss.
CMS, Vollständiger Name ConcurrentLowPausesecollector, ist ein neuer GC -Algorithmus, der in der späteren Version von JDK1.4 eingeführt wird. Es wurde in JDK5 und JDK6 weiter verbessert. Das wichtigste geeignete Szenario besteht darin, dass die Bedeutung der Reaktionszeit größer ist als die Anforderungen für den Durchsatz, können Müllfäden und Anwendungsfäden standhalten, die Prozessorressourcen teilen, und es gibt relativ viele Long-Lifetime-Objekte in der Anwendung. CMS wird zum Recycling von TenuredGeneration verwendet, dh Recycling älterer Menschen. Ziel ist es, die Anwendungs -Pause -Zeit zu minimieren, die Wahrscheinlichkeit eines FullGC -Auftretens zu verkürzen und mit Anwendungsfäden gleichzeitig die älteren Menschen zu markieren und zu löschen.
-Xx:+useconcmarksweepgc: Setzen Sie die alte Generation auf die gleichzeitige Sammlung. Nach der Konfiguration dieser im Test ist die Konfiguration von -xx: newRatio = 4 ungültig. Daher ist es am besten, die Größe der jungen Generation zu diesem Zeitpunkt mit -xmn zu setzen.
-Xx: cmsfullgcsBeForeCompaction =: Da der gleichzeitige Kollektor den Speicherraum nicht komprimiert oder organisiert, werden "Fragmente" nach einer Zeitspanne erzeugt, die die Betriebseffizienz verringert. Dieser Parameter legt den Speicherplatz fest, der nach dem Ausführen von FullGC komprimiert und organisiert wird.
-Xx:+usecmscompactatfulCollection: Schalten Sie die Komprimierung für ältere Generationen ein. Kann die Leistung beeinflussen, kann jedoch Speicherfragmentierung beseitigen.
-Xx:+cmsincrementalMode: auf inkrementelle Sammlungsmodus einstellen. Allgemein anwendbar auf einzelne CPU -Situationen.
-Xx:
HINWEIS: Wenn Sie zwei Müllkollektoren, Durchsatz- und ConcurrentLowPausesecollector verwenden, müssen Sie eine ordnungsgemäße hohe Speichergröße haben, um sich auf Multi-Threading vorzubereiten.
andere
-Xx:+scavengeBeFefulgc: Die nächste Generation von GC hat Vorrang vor FullgC.
-Xx: -disableExPlicitGC: Hemmung des Aufrufsystems.gc (), aber der GC des JVM ist immer noch gültig.
-Xx:+maxfdlimit: Maximieren Sie die Grenze für die Anzahl der Dateideskriptoren.
-Xx:+UsethreadPriorities: Aktivieren Sie die lokale API der Thread -Priorität, auch wenn Java.lang.Thread.setPriority () wirksam wird, ist es ungültig.
-Xx: SoftreflrupolicymSpermb = 0: Das Objekt "Soft Referen" kann nach dem letzten Zugriff 0 Millisekunden überleben (Standard ist 1 Sekunde).
-Xx: targetsurvivorratio = 90: Ermöglicht, dass 90% des Überlebensraums besetzt werden (Standard ist 50%). Erhöhen Sie die Nutzungsrate des Überlebenden - Wenn Sie sie überschreiten, werden Sie die Müllsammlung ausprobieren.
Hilfsinformationen
-Xx: -Kitime: Der Druck verbraucht Zeit in der JIT-Zusammenstellung
-Xx: errorFile =./Hs_err_pid.log: Fehlerprotokoll oder Daten in der angegebenen Datei speichern
-Xx: -euteddeddtraceProbes: Schalten Sie die solaris-spezifische DTRACE-Sonde ein
-Xx: heapdumppath =./Java_pid.hprof: Gibt den Pfad oder den Dateinamen beim Exportieren von Heap -Informationen an
-Xx: -HeapdumponoutofMemoryError: Relevante Informationen im Heap exportieren zu diesem Zeitpunkt, wenn der Speicherüberlauf zum ersten Mal auftritt.
-Xx: onError = ";": Führen Sie den benutzerdefinierten Befehl aus, nachdem ein tödlicher Fehler angezeigt wurde
-Xx: onoutofMemoryError = ";": Benutzerdefinierte Befehl ausführen
-Xx: -printclasshistogramm: Drucken von Spalteninformationen der Klasseninstanz nach der Begegnung mit Strg-Break, die gleiche wie die JMAP-Histo-Funktion
-Xx: -printconcurrentLocks: Drucken Sie verwandte Informationen zu gleichzeitigen Sperren nach der Begegnung mit Strl-Break, genau wie die JStack-L-Funktion
-Xx: -printcommandlineflags: Druckmarken, die in der Befehlszeile angezeigt werden
-XX: -printkompilation: Relevante Informationen drucken, wenn eine Methode zusammengestellt wird
-XX: -printgc: Drucken Sie jedes Mal relevante Informationen, wenn GC
-XX: -printgcdetails: DETALIEN JEDERBEDEHEN GC DETAILEN DETAILEN
-Xx: -printgctimestamps: Drucken Sie den Zeitstempel jedes GC aus
-Xx: -TraceClassLading: Verfolgen Sie die Ladeinformationen der Klasse
-Xx: -TraceClassLoadingPreorder: Verfolgt die Ladeinformationen aller Klassen, auf die verwiesen wird
-Xx: -TraceClassResolution: Tracking Constant Pool verfolgen
-Xx: -TraceClassUnloading: Verfolgung von Klassenentladeninformationen
-Xx: -Traceloaderconstraints: Verfolgung von Informationen zu Klassenladerbeschränkungen verfolgen
JVM -Service -Tuning -Praxis
Server: 8Cup, 8GMEM
z.B
Java-XMX3550M-XMS3550M-XSS128K-XX: NewRatio = 4-XX: SURPIVORRATIO = 4-XX: MaxpermSize = 16M-XX: maxtenuringThreshold = 0
Tuningplan:
-Xmx5g: Stellen Sie den maximal verfügbaren Speicher von JVM auf 5G ein.
-Xms5g: Setzen Sie den anfänglichen JVM -Speicher auf 5G. Dieser Wert kann genauso wie -xmx festgelegt werden, um jedes Mal, wenn die Müllsammlung abgeschlossen ist, den Reallocing -Speicher von JVM zu vermeiden.
-Xmn2g: Setzen Sie die Größe der jungen Generation auf 2G. Die gesamte Haufenspeichergröße = Größe der Jugendgenerierung + alte Generationsgröße + persistierende Erzeugungsgröße. Die dauerhafte Erzeugung ist im Allgemeinen in einer Größe von 64 m festgelegt. Nach der Erhöhung der jüngeren Erzeugung wird die Größe der älteren Generation verringert. Dieser Wert hat einen großen Einfluss auf die Systemleistung, und Sun empfiehlt die Konfiguration offiziell als 3/8 des gesamten Haufens.
-Xx:+useParnewgc: Setzen Sie die junge Generation auf eine parallele Sammlung. Kann gleichzeitig mit der CMS -Sammlung verwendet werden. JDK5.0 oder höher, der JVM wird es selbst gemäß der Systemkonfiguration festlegen, sodass dieser Wert nicht erneut festgelegt werden muss.
-Xx: ParallelgcThreads = 8: Die Anzahl der Threads zum Konfigurieren des parallelen Kollektors, dh wie viele Fäden werden gleichzeitig Müll gesammelt. Dieser Wert ist am besten so konfiguriert, dass er der Anzahl der Prozessoren entspricht.
-Xx: Survivorratio = 6: Legt das Größenverhältnis des Edenbereichs und des Überlebendenbereichs in der jungen Generation fest. Laut Erfahrung beträgt das Verhältnis der beiden Überlebendenzonen zu einer Edenzone 2: 6, und eine Überlebendenzone ist 1/8 der gesamten jungen Generation aus.
-Xx: maxtenuringThreshold = 30: das maximale Müllalter (Häufigkeit) einstellen. Wenn die Objekte der jüngeren Generation auf 0 gesetzt, treten Objekte direkt in die ältere Generation ein, ohne den Survivor -Bereich zu durchlaufen. Für mehr Anwendungen in der älteren Generation kann die Effizienz verbessert werden. Wenn dieser Wert auf einen größeren Wert eingestellt wird, kopiert das Objekt der jungen Generation mehrmals im Survivor -Bereich, was die Überlebenszeit des Objekts und die jüngere Generation erhöhen und die Wahrscheinlichkeit erhöhen kann, dass er in der jüngeren Generation recycelt wird. Eingestellt auf 30 bedeutet, dass ein Objekt in der alten Generation platziert wird, wenn es sich 30 Mal im Überlebendenraum bewegt und nicht recycelt wurde.
-Xx:+useconcmarksweepgc: Setzen Sie die alte Generation auf die gleichzeitige Sammlung. Nach dem Testen und Konfigurieren dieses Parameters ist der Parameter -xx: newratio = 4 ungültig. Daher ist es am besten, die Größe der jungen Generation mit -xmn festzulegen, sodass dieser Parameter nicht empfohlen wird.
Referenzen - Erzeugung von JVM Heap -Speicher
Der Heap -Speicher virtueller Maschinen ist in drei Generationen unterteilt: junge Generation, alte Generation und dauerhafte Generation. Unter ihnen speichert die persistente Generation hauptsächlich die Informationen der Java -Klasse, die wenig mit den Java -Objekten zu tun haben, die vom Müllsammler gesammelt werden können. Daher hat die Trennung zwischen der jüngeren Generation und der älteren Generation einen größeren Einfluss auf die Müllsammlung.
Junge Generation
Alle neu erzeugten Objekte werden zuerst in der jüngeren Generation platziert. Das Ziel der jüngeren Generation ist es, Objekte mit kurzen Lebenszyklen so schnell wie möglich zu sammeln. Junge Generationen sind in drei Gebiete unterteilt. Ein Eden -Gebiet, zwei Überlebendegebiete (im Allgemeinen).
Die meisten Objekte werden im Eden -Bereich erzeugt. Wenn der Eden -Bereich voll ist, werden die immer noch überlebenden Objekte in den Survivor -Bereich (einer der beiden) kopiert. Wenn ein Überlebenderbereich voll ist, werden die überlebenden Objekte in diesem Bereich in einen anderen Überlebendenbereich kopiert. Wenn der andere Überlebendebereich ebenfalls voll ist, werden die Objekte aus dem vorherigen Überlebendenbereich kopiert und werden zu diesem Zeitpunkt immer noch überlebt, um in den "festen Bereich" zu kopieren.
Es ist zu beachten, dass die beiden Überlebendenbereiche symmetrisch sind und keine Beziehung in der Sequenz haben. Daher können Objekte aus dem Edenbereich kopiert und Objekte gleichzeitig aus dem anderen Überlebendenbereich im selben Überlebendenbereich kopiert. und nur Objekte, die in den alten Bereich kopiert wurden (relativ). Darüber hinaus gibt es immer einen im Survivor -Bereich, der leer ist. In besonderen Fällen kann nach den Programmanforderungen der Überlebendebereich in mehreren (mehr als zwei) konfiguriert werden, was die Existenzzeit der Objekte in der jüngeren Generation erhöhen und die Möglichkeit verringern kann, in der älteren Generation platziert zu werden.
Ältere Generation
Objekte, die nach N (konfigurierbar) Müllsammlungen in der jüngeren Generation noch überleben, werden in der älteren Generation platziert. Daher kann berücksichtigt werden, dass ältere Menschen Objekte mit längeren Lebenszyklen speichern.
Anhaltende Generation
Wird verwendet, um statische Daten wie Javaclass, Methode usw. zu speichern. Die persistente Generation hat keinen signifikanten Einfluss auf die Müllsammlung, aber einige Anwendungen können einige Klassen wie Winterhinne usw. dynamisch generieren oder aufrufen. Zu diesem Zeitpunkt muss ein relativ großer persistierter Generationsraum eingerichtet werden, um diese Typen zu speichern, die während des Betriebs dynamisch erhöht werden. Die persistente Generationsgröße ist durch -xx festgelegt: maxpermsize =.
Zusammenfassen
Das obige ist der gesamte Inhalt dieses Artikels zur Optimierung von Java Virtual Machine (JVM -Tuning). Ich hoffe, es wird für alle hilfreich sein. Interessierte Freunde können weiterhin auf andere verwandte Themen auf dieser Website verweisen. Wenn es Mängel gibt, hinterlassen Sie bitte eine Nachricht, um darauf hinzuweisen. Vielen Dank an Freunde für Ihre Unterstützung für diese Seite!