Nous exécutons plusieurs services Java (Corretto JDK21) sur AWS Elastic Container Service (ECS) Fargate. Chaque service possède son propre conteneur et nous souhaitons utiliser toutes les ressources possibles que nous payons pour chaque processus. Mais les étapes peuvent être appliquées à EC2 et à d’autres cloud.

Les services exécutent des tâches par lots et la latence n'est pas importante, nous utilisons Parallel GC (-XX : UseParallelGC). Peut-être que G1 serait meilleur même avec nos tâches, mais c'est un sujet de recherche et de publication séparé.
Pour utiliser toute la mémoire disponible, nous MaxHeapSize est un peu inférieur à la taille de la mémoire du conteneur. Mais après un certain temps, nous avons remarqué deux problèmes : parfois nos conteneurs étaient tués car ils utilisaient trop de mémoire et parfois nous recevions des exceptions OutOfMemoryError. Pour corriger le premier, nous avons augmenté l'écart entre la taille de la mémoire du conteneur et MaxHeapSize et pour le second, nous avons augmenté la mémoire des conteneurs comme solution rapide et avons commencé à examiner les vidages de tas.

Les vidages de tas montraient des détails intéressants, la taille réelle du tas était inférieure à MaxHeapSize et le tas de la jeune génération était minuscule par rapport à l'ancienne génération.

La recherche sur Internet n'a pas aidé à trouver un bon guide sur la façon de régler les paramètres JVM pour notre cas, je n'ai trouvé que quelques détails de haut niveau sur les tas et les descriptions de paramètres. J'ai décidé d'écrire cet article pour décrire les étapes que j'ai effectuées.

Les premières étapes ont été :

• imprimer des informations sur les paramètres et les valeurs par défaut : (-XX : PrintFlagsFinal),
• définissez InitialHeapSize sur la même valeur que MaxHeapSize (-XX:InitialRAMPercentage=100 ou définissez simplement -XX:InitialHeapSize sur la même valeur que MaxHeapSize). De toute façon, nous payons pour toute la mémoire du conteneur, alors pourquoi ne pas l'allouer dès le départ ?
• enregistrer les informations sur le GC et le tas (-Xlog:gc*).

Le taux par défaut pour les jeunes : anciennes générations est de 1 : 2, et seule une partie de la jeune génération est utilisée en même temps pour effectuer du GC. Et après le démarrage, la JVM a alloué toute la mémoire comme prévu, mais après un certain temps, elle a commencé à réduire la taille du tas de la jeune génération à presque plusieurs mégaoctets. Ainsi, après un certain temps, nous n’avons utilisé que les ⅔ de la mémoire disponible.
Après quelques recherches, j'ai trouvé un paramètre pour désactiver la politique adaptative (-XX:-UseAdaptiveSizePolicy) et cela a aidé, le tas a cessé de diminuer et les intervalles entre les garbage collection ont augmenté d'un ordre de grandeur, voire plus. Le temps consommé par GC a également augmenté, mais pas autant.

L'étape suivante consistait à trouver l'écart optimal entre la taille de la mémoire du conteneur. Par défaut, même si InitialRAMPercentage=100, JDK alloue simplement de la mémoire et ne l'utilise pas, elle n'est donc pas mappée. Linux lui permet d'allouer plus de mémoire virtuelle que de mémoire physique. Et le conteneur échoue plus tard lorsque la mémoire est réellement mappée (JDK y écrit). -XX : AlwaysPreTouch modifie ce comportement. Malheureusement, une partie de la mémoire n'est toujours pas mappée, mais la terminaison du MOO se produit beaucoup plus rapidement. Après plusieurs tentatives, j'ai opté pour la formule suivante Taille de la mémoire du conteneur : 1 024 Mo pour les conteneurs dotés de 8 Go de mémoire ou plus. Par exemple, pour une taille de mémoire de conteneur de 8 192, nous utilisons -XX:MaxHeapSize=7168m.

Pour des optimisations supplémentaires, nous envisageons de modifier -XX:NewRatio pour diminuer la taille de la jeune génération et réduire le temps de GC. Mais cela dépend de la durée de vie de l'objet dans l'application.
Comme je l'ai mentionné précédemment, je n'ai trouvé aucun bon guide avec une explication détaillée des paramètres (le meilleur que j'ai trouvé est vm-options-explorer) et des étapes de réglage. Ce serait formidable si vous pouviez partager vos connaissances et vos résultats.