Les essentiels de la JVM pour Elasticsearch : métriques, mémoire et monitoring

Elasticsearch est un moteur de recherche et d'analyse basé sur Java ainsi qu'une base vectorielle reposant sur Apache Lucene ; il constitue le noyau de la plateforme Elasticsearch. Pour exécuter Elasticsearch sur ses plateformes prises en charge, vous avez besoin d'une machine virtuelle Java (JVM). La JVM fournit un environnement d'exécution indépendant de la plateforme, et vous pouvez exécuter Elasticsearch dans un environnement virtuel au-dessus du système d'exploitation existant. La JVM abstrait le système d'exploitation et le matériel sous-jacents, de sorte que les applications Java peuvent être en exécution sur n'importe quelle Platform.

Comprendre la gestion de la mémoire de la JVM et la récupération des objets via le garbage collection (GC) est la clé pour résoudre des problèmes tels que java.lang.OutOfMemoryError (code de sortie 127). Ces problèmes surviennent lorsque l’exécution de la JVM manque de mémoire ou en cas de code de sortie 137, ce qui indique généralement que le processus OOM (Out-Of-Memory) killer de l'hôte a arrêté le processus JVM en raison d'une utilisation excessive de la mémoire. Ce blog vous guidera sur la façon d'examiner les modèles d'utilisation de la mémoire et de résoudre ces problèmes de JVM.

J'expliquerai également le rôle de la JVM et comment le corréler à l'aide des API Elasticsearch existantes, en fournissant de précieuses informations sur l'état de la JVM Elasticsearch et en vous aidant à décider si vous souhaitez l'optimiser davantage en fonction de votre propre cas d'utilisation. 

Comme indiqué dans la documentation JVM d'Elasticsearch, les valeurs par défaut des options JVM fournies avec le produit fonctionnent efficacement dans tous les environnements de production pris en charge ; ces valeurs par défaut peuvent gérer la plupart des cas d'utilisation pour les opérations de recherche et d'indexation. Il n'est pas recommandé de modifier les valeurs ou d'ajouter des valeurs personnalisées pour les options ou les paramètres JVM.

Une machine virtuelle Java fait partie intégrante de l'environnement d'exécution Java (JRE), qui est fourni avec un kit de développement Java (JDK).

La JVM est similaire à un programme informatique qui aide à l'exécution des applications Java. Elle n'existe pas en tant que machine physique, mais elle se comporte comme telle en traduisant le code Java en instructions que votre système d'exploitation pris en charge peut comprendre. La JVM prend également en charge des tâches importantes telles que la gestion de la mémoire, le traitement de la récupération de mémoire et la sécurisation de vos applications.

Ensuite, concentrons-nous sur la gestion de la mémoire JVM et le garbage collection — un point majeur dans Elasticsearch que nous vérifions fréquemment lors du dépannage de tout problème de performance mémoire ou lié à une erreur OOM.

Pour comprendre la gestion de la mémoire et le garbage collection, vous devez d'abord comprendre la représentation logique de la zone de segment de mémoire (ou segment de mémoire) où résident tous les objets au démarrage d'une JVM.

Zone/région de jeune génération
Lorsqu’une application Java démarre, elle crée de nouveaux objets et les alloue à la zone appelée segment de mémoire. L’espace Eden de la jeune génération est le premier endroit où l’application alloue les objets nouvellement créés. Cette zone est réservée à l’allocation de nouveaux objets. Lorsqu’elle est pleine, les objets éligibles sont soit supprimés (garbage collected), soit promus vers d’autres régions.

Lorsqu'une récupération de mémoire mineure se produit, les objets référencés sont déplacés vers une autre sous-section, la région Survivor S0. Les objets non référencés sont supprimés pour libérer de l'espace dans Eden. Cette région contient les objets qui ont survécu au processus de récupération de mémoire, d'où le nom région Survivor. 

Le même cycle se répète lorsque l'espace Eden est à nouveau plein. Cette fois, les objets ayant survécu à Eden et à S0 seront déplacés vers la région S1, et ce processus se poursuit. 

Les objets ayant survécu aux récupérations de mémoire dans Eden, S0 et S1 seront promus vers l'ancienne génération en fonction du calculateur d'âge.

Zone/région de l'ancienne génération
L'ancienne génération (aussi appelée génération tenured) est une collection d'objets à longue durée de vie ayant survécu aux multiples événements de garbage collection dans la jeune génération (GC mineurs). Les objets ayant survécu à un certain nombre de cycles dans l'espace survivant sont déplacés par l'algorithme vers l'ancienne génération, ce qu'on appelle aussi promotion d'objet.

Le modèle en dents de scie du GC ci-dessus, issu de Stack Monitoring, montre que lorsqu'une collecte de déchets mineure se produit, le segment de mémoire de la JVM diminue car le GC supprime les objets indésirables de la mémoire. Après quelques cycles, les objets s'accumulent et le GC (récupérateur de mémoire) se déclenche à nouveau pour les supprimer. 

Le G1GC a une cible de temps de pause (-XX:MaxGCPauseMillis=200) qu'il tente d'atteindre pendant la récupération de mémoire. Cela signifie que pendant la récupération de mémoire, il garantit que la JVM ne subit pas de pause supérieure à cette valeur, ce qui le rend meilleur que CMS ou d'autres récupérateurs où cette option n'existe pas. Dans l'ensemble, il est recommandé de conserver les paramètres de GC par défaut, ce qui maintiendra la pause GC dans les limites pour des performances améliorées. 

Cette API fournira les détails de la configuration du Node, y compris les arguments d'entrée JVM, les pools de mémoire et la taille du segment de mémoire. 

De plus, si vous souhaitez vérifier les indicateurs de la JVM Elasticsearch pour la disponibilité d'un Node particulier, le tas utilisé dans tous les pools de mémoire ou les statistiques sur le garbage collection, vous pouvez utiliser l'API Node statistics. Elle fournira des indicateurs détaillés sur chacune des métriques mentionnées.

Si vous êtes un utilisateur avancé et que vous souhaitez vérifier les statistiques en temps réel d’une JVM en cours d’exécution sans utiliser les API Elasticsearch, vous pouvez utiliser la version Java fournie et exécuter jstat pour vérifier les statistiques en direct. Pour ce faire, recherchez d’abord le répertoire d’installation de Java ou le répertoire bin, ainsi que le PID du processus Elasticsearch. Depuis le répertoire bin, utilisez l’outil jstat :

Ici, 2000 correspond à l’intervalle en millisecondes après lequel les statistiques seront récupérées et affichées sur la CLI. Cette commande est utile pour identifier la fréquence à laquelle le GC se produit dans toutes les zones et la vitesse à laquelle les pools de mémoire sont remplis par les objets (taux de création et de promotion des objets). 

Il ne s'agit pas d'une alternative aux API mentionnées ci-dessus, mais plutôt d'un outil destiné au débogage au niveau développeur.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.