Beispielanalyse zur JVM-Parameteroptimierung

Originalquelle:

In Bezug auf die Optimierung der JVM-Parameter bereitet es vielen Programmierern Kopfzerbrechen. Wenn die Einstellungen nicht gut sind, führt die JVM weiterhin den vollständigen GC aus Dadurch wird das gesamte System sehr langsam und die Website-Stagnationszeit kann mehr als 10 Sekunden betragen. Wenn dies alle paar Minuten passiert, kann ich es nicht ertragen.

Diese Art von Stagnation ist beim Testen nicht erkennbar. Das Problem tritt erst auf, wenn der PV-Wert der Website Hunderttausende pro Tag erreicht. Um die JVM-Parameter richtig zu konfigurieren, müssen Sie die Daten analysieren Sie haben ein gewisses Verständnis für die alte Generation, den Rettungsraum und die permanente Generation. Außerdem müssen Sie die JVM-Speicherverwaltungslogik verstehen und letztendlich Anpassungen entsprechend Ihrer eigenen Anwendung vornehmen. Sie können viele JVM-Parameter finden, indem Sie im Internet suchen, und es gibt viele praktische Beispiele. Ich habe auch verschiedene Beispiele getestet, aber nach mehreren Monaten des Übens und Verbesserns habe ich die Website (keine Anforderungen erforderlich). ) Die folgenden Erfahrungen werden für die Optimierung von JVM-Parametern (Totzeit) gegeben.

1: Es wird empfohlen, ein 64-Bit-Betriebssystem zu verwenden. Das 64-Bit-JDK unter Linux ist langsamer als das 32-Bit-JDK, verbraucht aber mehr Speicher und hat einen höheren Durchsatz.

2: Die XMX- und

3: Legen Sie beim Debuggen einige Druckparameter fest, z. B. -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log, damit Sie dies können Beginnen Sie mit GC. Einige Hinweise sind im .log zu sehen.

4: Wenn das System pausiert, liegt möglicherweise ein GC-Problem oder ein Programmproblem vor. Verwenden Sie Jmap und Jstack, um Java zu überprüfen, oder killall -3 und überprüfen Sie dann das Java-Konsolenprotokoll. Sie können viele Probleme sehen . Einmal wurde die Website plötzlich sehr langsam. Als Jstack nachschaute, stellte sich heraus, dass zu viele von ihm selbst geschriebene URL-Verbindungen nicht veröffentlicht wurden. Er änderte das Programm und es war in Ordnung.

5: Wenn Sie Caching verwenden, sollte die zwischengespeicherte HashMap nicht unendlich lang sein. Es wird empfohlen, die maximale Länge von zu verwenden LRUMap ist auch Es sollte entsprechend der tatsächlichen Situation eingestellt werden.

6: Eine fehlgeschlagene Beförderung ist ein Problem bei der Speicherbereinigung. Im Allgemeinen kann dies aus zwei Gründen auftreten. Der erste Grund ist, dass der Rettungsraum nicht ausreicht und die Objekte im Rettungsraum nicht verschoben werden sollten die alte Generation, aber es gibt viele Objekte in der jungen Generation, die in den Rettungsraum gestellt werden müssen; wird auf Full GC umgestellt und die Pausenzeit der Website wird länger. Meine letzte Lösung für den ersten Grund besteht darin, den Rettungsraum zu entfernen und -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 zu setzen. Meine Lösung für den zweiten Grund besteht darin, CMSInitiatingOccupancyFraction auf diese Weise auf einen bestimmten Wert zu setzen (vorausgesetzt, 70). , CMS wird ausgeführt, wenn der Speicherplatz der alten Generation 70 % erreicht, und die alte Generation verfügt über genügend Speicherplatz, um Objekte der jungen Generation zu akzeptieren.

7: Egal was passiert, die permanente Generation wird nach und nach voll, daher ist es notwendig, den Java-Server von Zeit zu Zeit neu zu starten. Ich starte ihn jeden Tag automatisch neu.

8: Bei Verwendung des gleichzeitigen Recyclings sollte die junge Generation kleiner und die alte Generation größer sein. Da die alte Generation das gleichzeitige Recycling verwendet, hat dies keine Auswirkungen auf den weiteren Betrieb anderer Programme und der Website Stoppen Sie, auch wenn es lange dauert, meine endgültige Konfiguration ist wie folgt (System 8G-Speicher), Millionen von PVs jeden Tag ohne Probleme, die Website wird nicht angehalten und die Website ist 2009 nicht aufgrund von Speicherproblemen ausgefallen .

2. $JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms6000M -Xmx6000M -Xmn500M -XX:PermSize=500M

4. -XX:MaxPermSize=500M -XX:SurvivorRatio=

   65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC

6. -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection

8. -XX:CMSFullGCsBeforeCompaction=

   0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled

10. -XX:CMSInitiatingOccupancyFraction=

    90 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram

12. -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log ";

Erklären Sie, dass -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 den Rettungsraum entfernt:

◆ -Xnoclassgc deaktiviert die Klassenbereinigung und die Leistung wird höher;
◆-XX:+DisableExplicitGC deaktiviert System.gc(), um zu verhindern, dass Programmierer versehentlich die gc-Methode aufrufen und die Leistung beeinträchtigen; für junge Leute Die Generation verwendet paralleles Multithread-Recycling, wodurch die Sammlung beschleunigt wird. Die CMS-Parameter beziehen sich auf das gleichzeitige Recycling.

CMSInitiatingOccupancyFraction

Das Festlegen dieses Parameters erfordert viel Geschick. Wenn (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn erfüllt ist, ist dies der Fall sei keine Beförderung fehlgeschlagen. In meiner Anwendung beträgt Xmx 6000 und die gleichzeitige Garbage Collection (CMS) beträgt der verbleibende 10 %-Speicherplatz zu diesem Zeitpunkt 5500 * 10 % = 550 MB, also selbst wenn alle Objekte in Xmn (also insgesamt 500 MB) vorhanden sind Die junge Generation wird auf die alte Generation verschoben, 550 MB. Es ist genügend Speicherplatz vorhanden. Solange die obige Formel erfüllt ist, kommt es daher nicht zu einem Promotion-Fehler während der Speicherbereinigung.

SoftRefLRUPolicyMSPerMB

Ich denke, dieser Parameter könnte nützlich sein, dass sanft erreichbare Objekte nach dem letzten Verweis noch einige Zeit am Leben bleiben. Der Standardwert ist eine Sekunde Lebensdauer pro freiem Megabyte Im Heap gibt es meiner Meinung nach keine Notwendigkeit, eine Sekunde zu warten.

Es gibt viele andere Einführungen zu JVM-Parametern. Es wird geschätzt, dass bei den meisten von ihnen keine Promotion fehlgeschlagen ist Die Anzahl der Besuche ist zu gering und es besteht keine Chance, darauf zu stoßen. Die Formel (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn ist auf jeden Fall originell. Wenn Sie wirklich auf „Promotion Failed“ stoßen, müssen Sie auf diese Weise damit umgehen.

Das obige ist der detaillierte Inhalt vonBeispielanalyse zur JVM-Parameteroptimierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!