Explication détaillée de l'optimisation du garbage collection pour les applications Java critiques (Partie 1)

Récemment, j'ai eu l'occasion de tester et d'optimiser plusieurs applications d'achat et de portail basées sur Java fonctionnant sur Sun/Oracle JVM. Les applications les plus visitées se trouvent en Allemagne. Dans de nombreux cas, le garbage collection est un facteur critique dans les performances du serveur Java. Dans cet article, nous étudierons quelques idées avancées d'algorithmes de récupération de place et certains paramètres d'ajustement importants. Nous comparons ces paramètres dans divers scénarios réels.

Du point de vue du garbage collection, les programmes serveur Java peuvent avoir une grande variété de besoins :

1. Certaines applications à fort trafic doivent répondre à un grand nombre de requêtes et créer de très nombreux objets. Parfois, certaines applications à trafic moyen utilisant des frameworks à forte consommation de ressources rencontreront le même problème. En bref, comment nettoyer efficacement ces objets générés est un défi de taille pour le garbage collection.

2. De plus, certaines applications doivent fonctionner pendant une longue période et fournir des services stables pendant le fonctionnement, ce qui exige que les performances ne se détériorent pas lentement avec le temps ou ne se détériorent pas soudainement.

3. Certains scénarios nécessitent des limites strictes sur le temps de réponse des utilisateurs (comme les jeux en ligne ou les applications de paris, etc.), et presque aucune pause GC supplémentaire n'est autorisée.

Dans de nombreux scénarios, vous pouvez combiner plusieurs exigences avec des priorités différentes. Plusieurs de mes exemples de programmes ont des exigences beaucoup plus élevées sur le premier point que sur le deuxième point, mais la plupart des programmes n'ont pas d'exigences élevées sur les trois aspects en même temps. Cela vous laisse une grande marge de manœuvre pour faire des compromis.

Performances de JVM GC sous configuration par défaut

JVM présente de nombreuses améliorations, mais elle ne peut toujours pas optimiser les tâches pendant l'exécution du programme. En plus des trois points mentionnés ci-dessus, les paramètres par défaut de la JVM ont une autre priorité : réduire l'utilisation de la mémoire. Considérez que des milliers d’utilisateurs ne fonctionnent pas sur des serveurs dotés de suffisamment de mémoire. Cela est également important pour de nombreux produits de commerce électronique, car ces applications sont configurées pour fonctionner la plupart du temps sur des ordinateurs portables de développement plutôt que sur des serveurs de base. Par conséquent, si votre serveur est configuré avec l'espace de mémoire minimum et les paramètres GC, tels que la configuration suivante,

java -Xmx1024m -XX:MaxPermSize=256m -cp Portal.jar my.portal.Portal

cela entraînera certainement un fonctionnement inefficace du système. Premièrement, il est recommandé de configurer non seulement la limite maximale de mémoire, mais également la taille initiale de la mémoire pour éviter que le serveur n'augmente progressivement la mémoire au démarrage. Sinon, cela coûtera très cher. Lorsque vous connaissez la quantité de mémoire dont votre serveur a besoin (et vous devriez le savoir à temps), c'est une bonne idée de définir la taille de mémoire initiale égale au paramètre de mémoire maximum. Il peut être défini via les paramètres JVM suivants :

-Xms1024m -XX:PermSize=256m

La dernière option de base qui est souvent configurée dans la JVM est de configurer la taille de la mémoire tas de nouvelle génération, de la même manière que celle définie ci-dessus :

-XX:NewSize=200m -XX:MaxNewSize=200m

Les sections suivantes expliqueront la configuration ci-dessus ainsi que des configurations plus complexes. Examinons d’abord une application de portail exécutée sur un hôte de test assez lent. Lors des tests de charge, comment fonctionne son garbage collection :

Figure 1 Comportement GC de la JVM avec une taille de tas légèrement optimisée en 25 heures environ (-Xms1024m - Xmx1024m -XX : NewSize=200m -XX:MaxNewSize=200m)

Parmi eux, la courbe bleue représente l'évolution de l'utilisation totale de la mémoire tas au fil du temps, et la ligne grise verticale représente l'intervalle de pause GC.

En plus du graphique, les indicateurs clés et les performances des opérations du GC sont affichés à l'extrême droite. Examinons d'abord la quantité moyenne de déchets créés (et collectés) au cours de ce test. La valeur de 30,5 Mo/s est marquée en jaune car il s'agit d'un taux de génération de déchets important mais acceptable, ce qui convient pour un exemple d'introduction au réglage du GC. D'autres valeurs indiquent les performances de la JVM dans le nettoyage de ces déchets : 99,55 % des déchets sont nettoyés dans la nouvelle génération, et seulement 0,45 % dans l'ancienne génération. Ce résultat est plutôt bon, il est donc marqué en vert.

La raison d'un tel résultat peut être vue à partir de l'intervalle de pause introduit par GC (et du thread de travail qui gère les requêtes des utilisateurs) : il existe de nombreux intervalles GC de nouvelle génération, mais très courts, en moyenne une fois toutes les 6 secondes, et la durée Cela ne prendra pas plus de 50 ms. Ces pauses ont arrêté la JVM pendant 0,77 % du temps total, mais chaque pause était totalement imperceptible pour l'utilisateur attendant la réponse du serveur.

En revanche, les pauses GC ancienne génération ne représentent que 0,19% du temps total. Cependant, pendant cette période, le GC d'ancienne génération n'a nettoyé que 0,45 % des déchets, tandis que le GC de nouvelle génération a mis 0,77 % du temps pour nettoyer 99,55 % des déchets. On peut voir à quel point le GC d’ancienne génération est inefficace par rapport au GC de nouvelle génération. De plus, le taux de déclenchement moyen des pauses GC d'ancienne génération est inférieur à une fois par heure, mais la durée moyenne peut atteindre 8 secondes, et la valeur aberrante maximale atteint même 19 secondes. Étant donné que ces pauses arrêtent en réalité le thread JVM traitant les demandes des utilisateurs, les pauses doivent être aussi rares et de courte durée que possible.

Grâce aux observations ci-dessus, nous pouvons dessiner les objectifs de base de réglage de la collecte des déchets générationnelle :

• Le GC de nouvelle génération devrait collecter autant de déchets que possible pour éviter des GC fréquent dans l’ancienne génération. Durée plus courte.

分代垃圾回收的基本思想与堆内存大小调整

先从下图开始。这个图可以通过JDK工具得到，比如jstat或者jvisualvm以及它的visualgc插件：

图2 JVM的堆内存结构，包括新生代的子分区（最左列）

Java的堆内存由永久代（Perm），老年代（Old）和新生代（New or Young）组成。新生代进一步划分为一个Eden空间和两个Survivor空间S0、S1。Eden空间是对象被创建时的地方，经过几轮新生代GC后，他们有可能被存放在Survivor空间。如果想了解更多，可以读一下Sun/Oracle的白皮书Memory Management in the Java HotSpot Virtual Machine

默认情况下，作为整体的新生代特别是Survivor空间太小，导致在GC清理大部分内存之前就无法保存更多对象。因此，这些对象被过早地保存在老年代中，这会导致老年代被迅速填满，必须频繁地清理垃圾。这也是图1中产生较多的Full GC暂停的原因。

（译者注：一般新生代的垃圾回收也称为Minor GC，老年代的垃圾回收称为Major GC或Full GC）

优化新生代内存大小

优化分代垃圾回收意味着让新生代，特别是Survivor空间，比默认情形大。但是同时也要考虑虚拟机使用的具体GC算法。

当前硬件上运行的Sun/Oracle虚拟机使用了ParallelGC作为默认GC算法。如果使用的不是默认算法，可以通过显式配置JVM参数来实现：

-XX:+UseParallelGC

默认情况下，这个算法并不在固定大小的Eden和Survivor空间中运行。它使用了一种自适应调整大小的策略，称为“AdaptiveSizePolicy”策略。正如描述的那样，它可以适应很多场景，包括服务器以外的机器的使用。但在服务器上运行时，这并不是最优策略。为了可以显式地设置固定的Survivor空间大小，可以通过以下JVM参数关闭它：

-XX:-UseAdaptiveSizePolicy

一旦这么设置后，就不能进一步增加新生代空间的大小，但我们可以有效地为Survivor空间设置合适的大小：

-XX:NewSize=400m -XX:MaxNewSize=400m -XX:SurvivorRatio=6

“SurvivorRatio=6”表示Survivor空间是Eden空间的1/6或者是整个新生代空间的1/8，在这个例子中就是50MB，而自适应大小策略经常运行在非常小的空间上，大约只有几MB。使用现在的配置，重复上面的负载测试，我们得到了下面的结果：

图3 堆内存优化后的JVM在50小时内的GC行为（-Xms1024m -Xmx1024m -XX:NewSize=400m -XX:MaxNewSize=400m -XX:-UseAdapativeSizePolicy -XX:SurvivorRatio=6）

这次的测试时间是上次的两倍，而垃圾的平均创建速率和之前基本一致（30.2MB/s，之前是30.5MB/s）。然而，整个过程只有两次老年代（Full）GC暂停，25小时左右才发生一次。这是因为老年代垃圾死亡速率（所谓的promation rate）从137kB/s减小到了6kB/s，老年代的垃圾回收只占整体的0.02%。同时新生代GC的暂停持续时间仅仅从平均48ms增加到57ms，两次暂停的间隔从6s增长到10s。总之，关闭了自适应大小调整，合理地优化堆内存大小，使GC暂停占总时间的比例从0.95%减小到0.59%，这是一个非常棒的结果。

优化后，使用ParNew算法作为默认ParallelGC的替代，也能得到相似的结果。这个算法是为了与CMS算法兼容而开发的，可以通过JVM参数来配置-XX:+UseParNewGC。关于CMS下面会提到。这个算法不使用自适应大小策略，可以运行在固定Survivor大小的空间上。因此，即使使用默认的配置SurvivorRatio=8，也比ParallelGC拥有更高的服务器利用率。

避免老年代GC的长时间暂停

上述结果的最后一个问题就是，老年代GC的长时间暂停平均为8s左右。通过适当的优化，老年代GC暂停已经很少了，但是一旦触发，对用户来说还是很烦人的。因为在暂停期间，JVM不能执行工作线程。在我们的例子中，8s的长度是由低速老旧的测试机导致的，在现代硬件上速度能快3倍左右。另一方面，现在的应用一般使用1G以上的堆内存，可以容纳更多的对象。当前的网络应用使用的堆内存能达到64GB，（至少）需要一半的内存来保存存活的对象。在这种情况下，8s对老年代暂停来说是很短的。这些应用中的老年代GC可以很随意地就接近1分钟，对于交互式网络应用来说是绝对不能接受的。

缓解这个问题的一个选择就是采用并行的方式处理老年代GC。默认情况下，在Java 6中，ParallelGC和ParNew GC算法使用多个GC线程来处理新生代GC，而老年代GC是单线程的。以ParallelGC回收器为例，可以在使用时添加以下参数：

-XX:+UseParallelOldGC

从Java 7开始，这个选项和-XX:+UseParallelGC默认被激活。但是，即使你的系统是4核或8核，也不要期望性能可以提高2倍以上。通常的结果会比2被小一些。在某些例子中，比如上述例子中的8s，这种提高还是比较有效的。但在很多极端的例子中，这还远远不够。解决方法是使用低延迟GC算法。

下篇中会讨论CMS（The Concurrent Mark and Sweep Collector）、幽灵般的碎片、G1（Garbage First）垃圾收集器和垃圾收集器的量化比较，最后给出总结。

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!