Analyse approfondie des principes de réglage JVM et des pratiques d'optimisation des services en ligne

• Raisons du réglage jvm-pourquoi le réglage jvm! (Loi de Hain, loi de Murphy)
• Le principe de l'algorithme de réglage jvm-garbage collection, comment régler
• Réglage jvm des paramètres de réglage jvm réels de l'ensemble de combat et test de résistance basé sur ces paramètres
• Jvm tuning gc log, en fonction de la situation du journal, ré-ajuster le service

1 Pourquoi le réglage JVM?

Réflexion 1: Après la mise en ligne du projet, qu'est-ce qui nous a amené à effectuer le réglage Jvm

• Trop de déchets (les threads java, les objets prennent de la mémoire), la mémoire est pleine et le programme ne peut pas fonctionner! !
• Il y a trop de threads de garbage collection et un garbage collection fréquent (les threads de garbage collection eux-mêmes occupent également des ressources: mémoire, ressources cpu), ce qui entraîne une diminution des performances du programme
• Le garbage collection fréquent provoque STW

Par conséquent, sur la base des raisons ci-dessus, une fois que le programme est en ligne, il doit être réglé, sinon les performances du programme ne peuvent pas être améliorées, c'est-à-dire qu'une fois le programme en ligne, une stratégie de récupération de place raisonnable doit être définie;

Réflexion 2: Quelle est l'essence du réglage jvm? ?

Réponse: Recyclez les déchets, recyclez les objets inutilisés à temps et libérez de l'espace mémoire dans le temps

Réflexion 3: En fonction de l'environnement du serveur, quelle quantité de mémoire doit être définie pour la mémoire du tas jvm?

• Capacité d'adressage du système d'exploitation 32 bits 2 ^ 32 = 4 Go, le plus grand peut prendre en charge 4 Go; jvm peut allouer 2 g +

• Système d'exploitation 64 bits - capacité d'adressage 2 ^ 64 = 16384PB, ordinateur hautes performances (IBM Z unix 128G 200+)
  

La mémoire de tas jvm ne peut pas être définie trop grande, sinon cela entraînera un temps d'adressage des ordures trop long, c'est-à-dire le STW de l'ensemble du programme, et ne peut pas être défini trop petit, sinon cela entraînera un ramassage des ordures trop fréquemment;

Organisation de quelques notes de documentation. J'ai également trié quelques documents d'entrevue et les dernières questions d'entrevue collectées par certaines grandes entreprises en 2020 (toutes organisées en documents, une petite partie des captures d'écran), si vous en avez besoin, veuillez cliquer ici, ici , et le code: CSDN.

Organisation de quelques notes de documentation. J'ai également trié quelques documents d'entrevue et les dernières questions d'entrevue collectées par certaines grandes entreprises en 2020 (toutes organisées en documents, une petite partie des captures d'écran), si vous en avez besoin, veuillez cliquer ici, ici , et le code: CSDN.

2 Principes de réglage JVM

1. gc time est suffisamment petit (le paramètre de mémoire du tas doit être suffisamment petit)
   

2. Le nombre de gc est assez petit (le paramètre de mémoire du tas est assez grand) ---- les ordures sont pleines (il faut beaucoup de temps pour remplir l'espace), puis le ramassage des ordures commence

3. L'occurrence du cycle complet de gc est suffisamment longue
   1) Le paramètre d'espace de génération permanente de metaspace est légèrement plus raisonnable, l'expansion de génération permanente, gc complet se produit immédiatement
   2) L'espace de réglage de l'ancienne génération est plus grand, si l'ancienne génération est pas plein, le gc complet ne se produira jamais
   3) Essayez de permettre la collecte des déchets dans la jeune génération
   4) Essayez de minimiser les gros objets

3 Principes de JVM Tuning-GC

3.1 Qu'est-ce que les déchets?

Il n'y a pas d'objets référencés dans la mémoire, ces objets sont des ordures, dans la mémoire du tas, une référence d'objet a disparu, puis l'objet doit être recyclé;

3.2 Comment trouver les ordures?

Il existe 2 types d'algorithmes de recherche de déchets dans JVM (la méthode de recherche de déchets)

• Algorithme de comptage de référence
• Algorithme d'accessibilité racine

1) Algorithme de comptage de références La méthode de l'

algorithme de comptage de références pour juger qu'un objet est des ordures consiste à juger que l'objet est des ordures lorsque le nombre est égal à 0; Il y a un problème: le problème du comptage de références circulaires ne peut pas être résolu; ce qui

précède les objets se réfèrent les uns aux autres, conduisant au comptage de références. Ce n'est toujours pas 0, donc il ne peut pas être jugé comme des déchets, mais aucun de ces objets n'est référencé par des objets externes, ils sont donc des déchets;

2) Algorithme d'accessibilité racine

L'algorithme d'accessibilité à la racine est actuellement l'algorithme de récupération de place principal utilisé par JVM; Oracle hotspot utilise cet algorithme;

3.3 Comment enlever les ordures?

JVM fournit 3 méthodes (algorithmes)

1. Algorithme de suppression de marque-balayage-marque
2. copie-copie
3. algorithme de compression de marque-compact

1) Mark-sweep - Algorithme de Mark sweep

1. Recherchez les déchets dans l'espace mémoire et marquez les déchets trouvés.
2. Supprimez les déchets marqués.

• Avantages: simple et efficace
• Inconvénients: il existe de nombreux espaces mémoire discontinus et l'espace mémoire est fragmenté, ce qui réduit l'efficacité et les performances d'adressage

2) Copie-Copie

1. Sélectionnez l'objet survivant
2. Copiez l'objet survivant dans l'autre moitié de l'espace, qui est l'espace mémoire continu
3. Après avoir copié tous les objets survivants, effacez directement la moitié supérieure de l'espace pour terminer les déchets collection ；

Avantages: Simple, l'espace mémoire est continu, pas besoin de s'inquiéter de la fragmentation de l'
espace mémoire Inconvénients: gaspillage d'espace mémoire

3) Algorithme de compression Mark-Compact Mark

1, marquer les déchets, ne pas effacer les déchets
2, numériser à nouveau et faire glisser (copier) les objets survivants (objets non marqués) à
une extrémité 3. Récupérer les déchets dans l'espace mémoire à l'autre extrémité

3.4 Ramasseurs d'ordures disponibles

Le langage Java a une fonctionnalité, il a son propre garbage collector; et il existe de nombreux garbage collector; par conséquent, vous devez choisir différents garbage collector selon différents scénarios;

JVM fournit 10 types de garbage collector; autant de garbage collector Collector, qui combinaison de garbage collector est utilisée dans le projet? ?

1) serial (garbage collection de jeune génération) + serialOld (recyclage des ordures dans l'ancienne génération): collecteur sérialisé, donc dans le processeur multicœur actuel, il ne convient pas, ne convient que pour le ramasse-miettes cpu monocœur;

2) parNew + CMS: parallèle; garbage collector simultané; cette combinaison donne la priorité à la combinaison garbage collector en temps de réponse

3) Parallel Scavenge + Parallel Old (abréviation: ps + po): garbage collector concurrent, qui est la combinaison de garbage collector par défaut de jdk

4) le garbage collector g1 (logiquement générationnel), qui combine la jeune génération et l'ancienne génération en un seul pour le ramasse-miettes;

3.5 Collecteur de déchets série

4 Modèle de génération de mémoire

Question: Que faites-vous après l'arrivée d'un gros objet? Eden peut le poser?

- Non - (YGC) - Eden peut le poser? - Non ---- l'ancien peut être en panne ---- Oui - peut être placé dans l'ancien ----- Non ---- fullgc oom

5 JVM tuning combat réel

Configuration du serveur: 4cpu, 8 Go de mémoire ---- le réglage jvm consiste en fait à définir une taille raisonnable de mémoire de tas jvm (ni trop grande ni trop petite)

-Xmx3550m  设置jvm堆内存最大值  (经验值设置： 根据压力测试，根据线上程序运行效果情况)
-Xms3550m  设置jvm堆内存初始化大小，一般情况下必须设置此值和最大的最大的堆内存空间保持一致，防止内存抖动，消耗性能
-Xmn2g 设置年轻代占用的空间大小
-Xss256k 设置线程堆栈的大小；jdk5.0以后默认线程堆栈大小为1MB; 在相同的内存情况下，减小堆栈大小，可以使得操作系统创建更多的业务线程；

Paramètres de mémoire de tas Jvm:

nohup java -Xmx3550m -Xms3550m -Xmn2g -Xss256k -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location = application.yaml> jshop.log 2> & 1 $ &

Courbe de performance TPS:

5.2 Analyser le journal gc

Si vous avez besoin d'analyser le journal gc, vous devez faire en sorte que le service gc entre les détails de gc dans le fichier journal, puis utilisez l'outil d'analyse de journal gc correspondant pour analyser le journal;

Exporter les détails de gc dans un fichier journal gc.log pour l'analyse gc

-XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: + PrintGCDateStamps
-XX: + PrintHeapAtGC -Xloggc: gc.log

Débit: temps d'exécution du thread métier / (temps gc + temps du thread métier)

analyse le journal gc et constate que 3 fullgc se sont produits au début. Il est évident qu'il y a un problème avec la configuration des paramètres d'optimisation jvm;

vérifier la cause du problème problème avec fullgc: jstat- gcutil pid

Génération persistante de Metaspace: la
taille d'allocation initiale est de 20m. Lorsque la métaspace est pleine, la génération persistante doit être étendue. Si la métaspace est étendue à chaque fois, fullgc doit être exécuté une fois; (fullgc reclaims tout l'espace du tas, ce qui prend du temps)

Ajuster la configuration gc: modifiez la taille d'initialisation de l'espace de génération permanent:

nohup java -Xmx3550m -Xms3550m -Xmn2g -Xss256k -XX: MetaspaceSize = 256m -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: + PrintGCDateStamps -XX: + PrintHeapAtGC -Xloggc: gc.log-1.0-shop -jar jar SNAPSHOT.jar --spring.addition-location = application.yaml> jshop.log 2> & 1 $ &

Après réglage, le phénomène fullgc a disparu:

5.3 Ratio jeunes et vieux

Rapport entre la jeune génération et l'ancienne génération: 1: 2 Paramètres: -XX: NewRetio = 4, ce qui signifie que le rapport entre la jeune génération (eden, s0, s1) et l'ancienne génération est de 1: 4

1) -XX: NewRetio = 4
La taille de la mémoire allouée par la jeune génération est devenue plus petite, donc le nombre de YGC a augmenté.Bien que le fullgc ne se produise pas, YGC prend plus de temps!

2) -XX: NewRetio = 2 Le nombre d'occurrences YGC diminuera inévitablement, parce que la taille de la zone eden devient plus grande, le YGC diminuera;

5.4 Eden et S0S1

Afin de réduire davantage YGC, vous pouvez définir le rapport entre la zone enden et s; méthode de réglage: -XX: SurvivorRatio = 8

1) Rapport de réglage: 8: 1: 1

2） Xmn2g 8: 1: 1

nohup java -Xmx3550m -Xms3550m -Xmn2g -XX: SurvivorRatio = 8 -Xss256k -XX: MetaspaceSize = 256m -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: + PrintGCDateStamps -XX: + PrintHeaplogAtGC -Xg jshop-web-1.0-SNAPSHOT.jar --spring.addition-location = application.yaml> jshop.log 2> & 1 $ &

Selon le réglage gc, le nombre de garbage collection, le temps et le débit sont tous une configuration relativement optimale;

5.5 Priorité de débit

En utilisant un garbage collector parallèle, vous pouvez utiliser pleinement les processeurs multicœurs pour aider au garbage collection; une telle méthode gc est appelée méthode de réglage du débit en premier.
Combinaison de garbage collector: ps (nettoyage parallèle) + po (ancien parallèle)
this Le garbage collector est la combinaison garbage collector par défaut de Jdk1.8;

nohup java -Xmx3550m -Xms3550m -Xmn2g -XX: SurvivorRatio = 8 -Xss256k -XX: + UseParallelGC -XX: UseParallelOldGC -XX: MetaspaceSize = 256m -XX: + PrintGCDetails -XX: + PrintGCTampStampXX: + PrintGCDetails -XX: + PrintGCTampStampXX: + PrintGCDetails -XX: + PrintGCTampStampXX: PrintHeapAtGC -Xloggc: gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location = application.yaml> jshop.log 2> & 1 $ &

5.6 Priorité du temps de réponse

L'utilisation de cms garbage collector est une combinaison de priorité de temps de réponse; cms garbage collector (garbage collection et exécution croisée des threads métier, ne permettra pas au thread métier de bloquer le stw) autant que possible pour réduire le temps de stw, utilisez donc le cms Combinaison de garbage collector, est la combinaison de priorité de temps de réponse

nohup java -Xmx3550m -Xms3550m -Xmn2g -XX: SurvivorRatio = 8 -Xss256k -XX: + UseParNewGC -XX: UseConcMarkSweepGC -XX: MetaspaceSize = 256m -XX: + PrintGCDetails -XX: + PrintGCTStampXX: + PrintGCDetails -XX: + PrintGCTStampXX PrintHeapAtGC -Xloggc: gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location = application.yaml> jshop.log 2> & 1 $ &

Il peut être constaté que le temps du ramasse-miettes cms devient plus long;

5,7 g1

La méthode de configuration est la suivante:

nohup java -Xmx3550m -Xms3550m -Xmn2g -XX: SurvivorRatio = 8 -Xss256k -XX: + UseG1GC -XX: MetaspaceSize = 256m -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: + PrintGCDateClogsHlogs -XXg: + PrintGCDateClogs -XXc gc.log -jar jshop-web-1.0-SNAPSHOT.jar --spring.addition-location = application.yaml> jshop.log 2> & 1 $ &

Faites attention, ne vous perdez pas! Si cet article vous est utile, n'oubliez pas d'aimer et de soutenir!