Surveillance du GC JVM : Causes profondes et recommandations

Description du problème

The Surconsommation du service JvmGcMonitor les avertissements indiquent que la Machine Virtuelle Java (JVM) effectue une collecte des ordures de la vieille génération (GC). Au cours de ce processus, la JVM suspend toutes les autres activités pour récupérer la mémoire, ce qui entraîne des perturbations potentielles telles que :

• Absence de réactivité des nœuds Elasticsearch aux requêtes client ou de cluster.
• Déconnexions de nœuds, ce qui peut entraîner une instabilité du cluster.

1. Utilisation excessive du tas: Un grand nombre de requêtes complexes ou trop de fragments alloués par rapport à la taille du tas JVM configurée.
2. Mauvaise configuration des ressources: Paramètres JVM mal alignés ou distributions des fragments incorrectes.

Constats et observations initiaux

1. Tendances de l’utilisation du tas:

• Examinez l’utilisation du tas JVM au fil du temps à l’aide d’outils de surveillance (par ex. : Stack Monitoring de Kibana ou métriques de l’ _nodes/stats API).
• Identifiez les périodes de saturation du tas ou de pauses GC prolongées.

1. Commande à utiliser :
2. GET /_nodes/stats/jvm
3. Allocation et taille des fragments:

• Passez en revue le nombre de fragments par nœud et leurs tailles en utilisant _cat/shards. Un nombre excessif de fragments entraîne une consommation de mémoire plus élevée.

1. Commande à utiliser :
2. GET /_cat/shards?v
3. Complexité des requêtes:

• Analysez les journaux de requêtes lentes ou surveillez les requêtes exécutées fréquemment. Les agrégations complexes ou les recherches par caractères génériques sollicitent souvent la mémoire JVM.

1. Commande pour activer les journaux lents :
2. # Ajouter à elasticsearch.yml
3. index.search.slowlog.threshold.query.warn: 10s
4. index.search.slowlog.threshold.fetch.warn: 5s
5. Modèles inhabituels:

• Vérifiez les pics d’indexation, les taux de recherche ou d’autres activités anormales lors des incidents de surconsommation GC.

Recommandations

Optimiser les paramètres du tas JVM:

• Assurez-vous que la taille du tas est définie de manière appropriée (50 % de la mémoire disponible, plafonnée à 30GB pour éviter la désactivation des pointeurs d’objets comprimés).
• Activez le G1GC, qui offre une meilleure performance pour les grands tas et les scénarios à haut débit.

Réduire le nombre de fragments:

• Combinez de petits index ou utilisez l’ Rollover API pour gérer la croissance des index.
• Visez 20 fragments par Go de mémoire de tas comme principe général.

Ajuster les requêtes:

• Réécrivez les requêtes coûteuses pour améliorer l’efficacité (par ex. : évitez * ou ? dans les caractères génériques).
• Mettez en cache les requêtes fréquemment utilisées en utilisant le cache des requêtes de recherche.

Mettre en place la surveillance et les alertes:

• Utilisez les outils de surveillance d’Elastic pour créer des alertes pour une utilisation élevée du tas ou des temps GC lents.

Évoluer le cluster:

• Si les demandes de charge de travail dépassent constamment la capacité, envisagez d’ajouter des nœuds au cluster pour répartir la charge.

Conclusion