Cette section introduit uniquement la partie de combat réelle. Pour des paramètres théoriques spécifiques, veuillez Baidu.
Outils requis: outil de test JMETER Linux Server Xshell Une application Web
Les paramètres JVM de Tomcat peuvent être configurés dans Catalina.sh, et s'il est sur la fenêtre, vous pouvez configurer le fichier .bat.
Configuration 1:
Ici, j'ai configuré un chemin de journal GC comme /home/log/gc.log pour imprimer le journal GC, le tas initial et la mémoire de tas maximum sont définis sur 50 m et lorsque le fichier de vidage de sortie est débordé, il utilise un collecteur de déchets série et que la taille de génération permanente est de 50 m.
Mettez l'application Web dans le répertoire correspondant, configure Server.xml (la configuration n'est pas introduite ici) et démarrez Tomcat.
Les tests de débit sont effectués à l'aide d'un outil de test de pression (JMeter). Les étudiants qui ne l'ont jamais utilisé peuvent télécharger et l'apprendre sur le site officiel http://jmeter.apache.org/
Créer un groupe d'utilisateurs (10 threads, chaque thread demande 1000 fois), configurer les informations de la demande HTTP, générer un rapport global et un journal GC
Jetons un coup d'œil au journal GC en premier:
GC complet à l'écran, vérifiez enfin le rapport global:
Le débit est maintenu à 122,7 par seconde. À partir de ce cas, nous pouvons voir que l'ancienne génération est fondamentalement pleine, et après FullGC, la nouvelle génération aura un peu à jouer. En général, le temps de pause du GC complet est le plus long et se produit si souvent, évidemment, une telle configuration est déraisonnable.
Configuration 2:
Cette configuration augmente principalement la mémoire de tas maximale. Afin d'étendre automatiquement la machine virtuelle et d'obtenir une taille de mémoire de tas stable.
Faites simplement attention à la mémoire de tas maximale de 82924K est d'environ 80 m, ce qui signifie que la machine virtuelle étend automatiquement la mémoire du tas à 80 m et la stabilise. Ce test de configuration est juste pour trouver une mémoire de tas stable pour le test suivant.
Configuration trois:
Réglez la mémoire initiale du tas de 128 m.
D'après les résultats de la configuration 2, on peut voir que la mémoire du tas est enfin stable à environ 80 m, donc une mémoire de tas inférieure à 80 m est susceptible de provoquer un grand nombre de réactions GC, donc je définis ici la mémoire du tas à 128 m, ce qui peut réduire le nombre de GC.
Vous pouvez voir que le débit a légèrement augmenté, le nombre de GC a considérablement diminué et les intervalles de temps des GC sont devenus plus longs.
Configuration 4:
Utilisant actuellement le recycleur ParallalGC, qui est un recycleur parallèle multithread.
Le débit du recycleur GC utilisant le parallèle multithread a été légèrement amélioré. (Parallalgc et SerialGC ont peu d'effet sur le débit sans pression GC.)
Configuration 5:
Configuration 6:
Selon la conclusion de la configuration 3, GC se produira fréquemment dans la mémoire du tas inférieur à 80 m. Combiné avec la conclusion obtenue dans la configuration 4, lorsqu'il y a une certaine pression GC, le débit de parallelGC et de SerialGC montrera certaines différences. Si la mémoire de tas de 5 et 6 est configurée avec 64 m <80 m, un GC fréquent se produira. Lorsque vous utilisez différents recycleurs GC, il y aura théoriquement une grande différence dans le débit, mais pourquoi la différence dans mon expérience n'est-elle pas très grande, et pourquoi? Hé, ma famille est pauvre. J'utilise un processeur monocore. Dans le cas de core unique, les changements de performances de ParallelGC ne sont pas évidents. SerialGC est recommandé lorsque les capacités monocomes ou parallèles sont faibles. Les étudiants qui ont les conditions peuvent l'essayer avec un serveur multi-fond!
Configuration 7:
Essayez d'utiliser Parnewgc. La nouvelle génération utilise ParnewGC pour recycler, tandis que l'ancienne génération utilise toujours SerialGC pour recycler. Voyez comment est la performance?
Il a de meilleures performances que d'utiliser un recycleur en série tous, mais des performances plus pires que d'utiliser un recycleur parallèle tout.
De plus, la mise à niveau de la version JDK peut également améliorer un peu les performances, mais la mise à niveau de la version JDK est livrée avec certains risques, et certains bugs inconnus peuvent être introduits dans la nouvelle version de JDK.
Enfin, j'ai répertorié certains paramètres de configuration JVM couramment utilisés pour référence:
1. Paramètres liés à la période de récupération en série
• -xx: + useeRerialgc: Utilisez des collectionneurs en série dans les nouvelles et anciennes générations
• -xx: survivratio: réglez la taille de la zone Eden et le rapport de la zone de survivante
• -xx: Pretenuresizethreshold: Réglez le seuil pour que les grands objets entrent directement dans la vieillesse. Lorsque la taille de l'objet dépasse cette valeur, elle sera allouée directement dans la vieillesse
• -xx: maxtrenuringthreshold: définit la valeur d'âge maximale de l'objet entrant dans la vieillesse. Après chaque GC mineur, l'âge du sujet est ajouté par 1. Tout objet supérieur à cet âge entrera certainement dans la vieillesse.
2. Paramètres parallèles liés à GC
• -xx: + useParNewgc: Utilisez des collectionneurs parallèles dans la nouvelle génération.
• -xx: + useParalleLoldGC: Utilisez des collectionneurs parallèles dans la vieillesse
• -xx: + parallelgThreads: définit le nombre de threads utilisés pour la collecte des ordures, qui peut généralement être défini pour être égal au nombre de processeurs. Lorsqu'il y a un grand nombre de processeurs, il est également possible de définir une valeur relativement petite.
• -xx: + maxgcpausemillis: définissez le temps de pause de collecte des ordures maximale. Sa valeur est un entier supérieur à 0.
• -xx: + useadaptivesizolicy: activez la stratégie GC adaptative. Dans ce mode, des paramètres tels que la taille de la nouvelle génération et le rapport de Survivio, et l'âge de l'objet dans l'ancienne génération seront automatiquement ajustés pour atteindre le point d'équilibre entre la taille du tas, le débit et la pause.
• -xx: + gctimeratio: définissez la taille du débit. Sa valeur est un certificat entre 0 et 100. En supposant que la valeur de Gctimeratio est N, le système ne passera pas plus de 1 / (1 + n) de temps sur la collecte des ordures.
3. Paramètres liés au collecteur CMS
• -xx: + useConcmarksweepgc: La nouvelle génération utilise des collectionneurs parallèles, tandis que l'ancienne génération utilise des collectionneurs CMS + série.
• -xx: parallelcmsThreads: définissez le nombre de threads pour CMS.
• -xx: CMSInitiatingoccupancyFraction: Définissez la quantité de collecteur CMS déclenché après l'utilisation de l'espace de vieillesse, par défaut 68%
• -xx: usecmscompactatfullcollection: Définissez si CMS doit défragmenter une fois après avoir terminé la collecte des ordures
• -xx: cmsfullgcBeForCompaction: Définissez le nombre de fois où la collection de déchets CMS est effectuée et la compression de la mémoire est effectuée.
• -xx: + cmsclassUnloadingEnabled: permet la récupération des métadonnées de classe
• -xx: CMSInitiatingPerMoccupancyFraction: Lorsque le rapport d'occupation permanent atteint ce pourcentage, démarrez la récupération CMS (à condition que -xx: + CMSClassUnloadingEnabled est activé)
• -xx: usecmsInitiatingOCcupancyLly: signifie que la récupération CMS n'est effectuée que lorsque le seuil est atteint.
• -xx: + cmsincrementalmode: utilisez le mode incrémentiel, qui convient plus à CPU unique. Le mode incrémentiel est marqué comme jeté au milieu et sera complètement supprimé dans JDK9.
4. Paramètres liés à la période de récupération G1
• -xx: + useg1gc: utilisez la récupération G1
• -xx: + maxgcpausemillis: définissez le temps de pause de collecte des ordures maximale
• -xx: + gcpauseInterValmillis: définissez l'intervalle de temps de pause.
5. TLAB lié
• -xx: + usetLab: activer l'allocation TLAB.
• -xx: + printtLab: Imprimer les informations d'allocation liées à TLAB
• -xx: TLABSIZE: Réglez la taille TLAB
• -xx: + resizetLab: ajustez automatiquement la taille TLAB
6. Quelques autres paramètres
• -xx: + DisableExplicitGC: Désactiver GC explicite
• -xx: + explicitgcinvokesconcurrent: utilisez la concurrence pour gérer le GC explicite
La performance JVM Tomcat ci-dessus pratique (recommandée) est tout le contenu que je partage avec vous. J'espère que vous pourrez vous faire référence et j'espère que vous pourrez soutenir Wulin.com plus.