Analyse des fichiers journaux GC (Garbage Collector) pour surveiller les problèmes de mémoire
Dans un environnement de production, il est recommandé d'activer la journalisation GC. Consultez la section
Surveillance de la consommation de mémoire d'un serveur ThingWorx pour plus d'informations sur l'activation de la journalisation GC. Une fois la journalisation GC activée, l'ensemble de l'activité GC sur le serveur est journalisée. Si la JVM ne répond pas sur de longues périodes, il se peut que les outils externes, comme PSM ou VisualVM par exemple, ne puissent pas collecter de données sur la mémoire. Toutefois, la JVM pourra imprimer l'activité GC, ce qui vous aidera à identifier la cause du problème de mémoire.
Lecture des journaux GC
Vous pouvez utiliser des outils tels que GCEasy.io et Chewiebug GC Viewer pour analyser les journaux GC. Vous pouvez également analyser les journaux GC manuellement dans un éditeur de texte pour résoudre les problèmes courants.
Chaque opération de nettoyage mémoire est généralement imprimée, comme illustré ci-dessous.
1. Temps écoulé depuis le démarrage de la JVM
2. Type de garbage collection (GC)
3. Motif du GC
4. Jeune génération nettoyée de 549M à 4M
5. Taille totale de la jeune génération
6. Durée d'exécution globale du GC
7. Segment alloué
8. Mémoire totale de l'application nettoyée par Java
Pour plus d'informations sur les opérations de GC, consultez la documentation Oracle.
Un outil d'analyse de GC permet de convertir la représentation textuelle des nettoyages en graphique plus lisible.
L'analyse des données du journal GC vous aide à identifier les scénarios suivants qui indiquent des problèmes de mémoire dans votre application ThingWorx :
• Opérations de GC complet très longues (45 secondes et plus) : les GC complets sont particulièrement indésirables dans la mesure où il s'agit d'opérations "stop-the-world". Par exemple, le GC complet suivant prend 46 secondes. Pendant ce temps, toutes les autres activités utilisateur sont interrompues :
272646.952: [Full GC: 7683158K->4864182K(8482304K) 46.204661 secs]
• GC complets en boucle : succession rapide de GC complets exécutés l'un après l'autre.
Par exemple, les quatre GC successifs suivants prennent deux minutes avant de se résoudre :
16121.092: [Full GC: 7341688K->4367406K(8482304K), 38.774491 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
• Dans le graphique suivant, les triangles rouges sur les pics du graphe sont autant d'indications visuelles de l'exécution de GC complets en boucle :
• Fuites de mémoire : surviennent lorsqu'un nombre croissant d'objets sont conservés en mémoire et que la mémoire ne peut pas être nettoyée.
Dans l'exemple suivant, la consommation de mémoire augmente régulièrement malgré les GC :
Recommandation : si vous ne disposez pas d'outil automatisé, tel que PSM, pour surveiller et enregistrer la consommation de mémoire dans le temps, examinez quotidiennement les fichiers journaux GC pour identifier les éventuels problèmes de mémoire. Lorsque des problèmes de mémoire surviennent, collectez les heap dumps ou les thread dumps JVM pour identifier les opérations longues. Ces opérations peuvent expliquer les problèmes de mémoire sous-jacents dans votre application ThingWorx.