Exemple d'analyse de réglage des paramètres JVM

Source originale :

Concernant le réglage des paramètres de la JVM, c'est un casse-tête pour de nombreux programmeurs. Si les paramètres ne sont pas bons, la JVM continuera à exécuter le Full GC, ce qui sera le cas. En conséquence, l'ensemble du système devient très lent et le temps de stagnation du site Web peut atteindre plus de 10 secondes. Si cela se produit toutes les quelques minutes, je ne pourrai pas le supporter.

Ce type de stagnation n'est pas visible lors des tests. Le problème n'est exposé que lorsque le pv du site Web atteint des centaines de milliers/jour. Afin de configurer correctement les paramètres JVM, vous devez analyser les jeunes. et les anciennes générations. Vous avez une certaine compréhension de l'ancienne génération, de l'espace de secours et de la génération permanente , et vous devez également comprendre la logique de gestion de la mémoire JVM, et finalement faire des ajustements en fonction de votre propre application. Vous pouvez trouver de nombreux paramètres JVM en effectuant une recherche sur Internet, et il existe de nombreux exemples pratiques. J'ai également testé divers exemples, mais des problèmes finiront par survenir. Après plusieurs mois de pratique et d'amélioration, j'ai le site Web (aucune exigence requise). ) Les expériences suivantes sont données pour le réglage des paramètres JVM (temps mort).

1 : Il est recommandé d'utiliser un système d'exploitation 64 bits. Le JDK 64 bits sous Linux est plus lent que le JDK 32 bits, mais consomme plus de mémoire et a un débit plus élevé.

2 : Les paramètres XMX et XMS ont la même taille, et les paramètres MaxPermSize et MinPermSize sont de la même taille, ce qui peut réduire la pression causée par la taille du tas de mise à l'échelle.

3 : Définissez certains paramètres d'impression pendant le débogage, tels que -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log, afin que vous puissiez démarrer à partir de gc Certains indices peuvent être vus dans le .log.

4 : Lorsque le système s'arrête, il peut s'agir d'un problème de GC ou d'un problème de programme. Utilisez Jmap et Jstack pour vérifier, ou killall -3 Java, puis vérifiez le journal de la console Java, vous pouvez voir de nombreux problèmes. . Un jour, le site Web est soudainement devenu très lent. Lorsque Jstack a jeté un coup d'œil, il s'est avéré qu'il y avait trop de connexions URL écrites par lui-même et qu'elles n'étaient pas publiées. Il a modifié le programme et tout s'est bien passé.

5 : Comprenez soigneusement votre application. Si vous utilisez la mise en cache, l'ancienne génération doit être plus grande. Le HashMap mis en cache ne doit pas être infiniment long. Il est recommandé d'utiliser l'algorithme LRU Map pour la mise en cache. LRUMap est également Il doit être défini en fonction de la situation réelle.

6 : L'échec de la promotion est un casse-tête lors de la collecte des ordures. Généralement, cela peut se produire pour deux raisons. La première raison est que l'espace de secours n'est pas suffisant et que les objets qui s'y trouvent ne doivent pas être déplacés. l'ancienne génération, mais il y a beaucoup d'objets de la jeune génération qui doivent être placés dans l'espace de sauvetage ; la deuxième raison est que l'ancienne génération n'a pas assez d'espace pour accepter les objets de la jeune génération ; passera à Full GC et le temps de pause du site Web sera plus long. Ma solution finale pour la première raison est de supprimer l'espace de secours et de définir -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0. Ma solution pour la deuxième raison est de définir CMSInitiatingOccupancyFraction sur une certaine valeur (en supposant 70 de cette manière). , CMS sera exécuté lorsque l'espace de l'ancienne génération atteindra 70 %, et l'ancienne génération aura suffisamment d'espace pour accepter les objets de la jeune génération.

7 : Quoi qu'il en soit, la génération permanente va progressivement se remplir, il est donc nécessaire de redémarrer le serveur Java de temps en temps, je le redémarre automatiquement chaque jour.

8 : Lors de l'utilisation du recyclage simultané, la jeune génération devrait être plus petite et l'ancienne génération devrait être plus grande. Étant donné que l'ancienne génération utilise le recyclage simultané, cela n'affectera pas le fonctionnement continu des autres programmes et le site Web ne le sera pas. arrêter même si cela prend du temps, ma configuration finale est la suivante (mémoire système 8G), des millions de PV chaque jour sans aucun problème, le site ne s'arrête pas, et le site n'est pas tombé en panne à cause de problèmes de mémoire en 2009. .

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 ";

Expliquez que -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 supprime l'espace de secours :

◆ -Xnoclassgc désactive le garbage collection de classe et les performances seront plus élevées ;
◆-XX:+DisableExplicitGC désactive System.gc() pour empêcher les programmeurs d'appeler par erreur la méthode gc et d'affecter les performances ; pour les jeunes La génération utilise le recyclage parallèle multithread, ce qui accélère la collecte, les paramètres CMS sont liés au recyclage simultané.

CMSInitiatingOccupancyFraction

Il faut beaucoup de compétences pour définir ce paramètre. Fondamentalement, si (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn est rencontré, il y aura. aucune promotion n'a échoué. Dans mon application, Xmx vaut 6 000 et Concurrent garbage collection (CMS), les 10 % d'espace restant à ce moment-là sont de 5 500*10 %=550 Mo, donc même si tous les objets dans Xmn (c'est-à-dire un total de 500 Mo dans la jeune génération) sont déplacés vers l'ancienne génération, 550 Mo Il y a suffisamment d'espace, donc tant que la formule ci-dessus est respectée, il n'y aura pas d'échec de promotion lors du ramasse-miettes

SoftRefLRUPolicyMSPerMB

Je pense que ce paramètre peut être utile. L'explication officielle est que les objets facilement accessibles resteront vivants pendant un certain temps après leur dernière référence. La valeur par défaut est d'une seconde de durée de vie par mégaoctet libre. dans le tas, je pense qu'il n'est pas nécessaire d'attendre 1 seconde ;

Il existe de nombreuses autres introductions aux paramètres JVM sur Internet. On estime que la plupart d'entre elles n'ont pas rencontré d'échec de promotion, ni le nombre de. Les visites sont trop petites et il n'y a aucune chance de le rencontrer. La formule (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn Certainement originale Si vous rencontrez vraiment un échec de promotion, vous devez le gérer de cette façon.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!