En tant qu’auteur de GCeasy – Outil d’analyse des journaux de collecte de déchets, je vois encore et encore quelques modèles de collecte de déchets intéressants. Sur la base du modèle de collecte des déchets, vous pouvez détecter instantanément les caractéristiques de santé et de performances de l’application. Dans cet article, permettez-moi de partager quelques modèles intéressants de collecte des ordures qui m’ont intrigué.
1. Motif en dents de scie sain
Vous verrez un beau motif GC en dents de scie lorsqu’une application est saine, comme le montre le graphique ci-dessus. L’utilisation du tas continuera d’augmenter ; une fois qu’un événement « Full GC » est déclenché, l’utilisation du tas chutera jusqu’en bas.
Dans la figure 1, vous pouvez remarquer que lorsque l’utilisation du tas atteint environ 5,8 Go, l’événement « Full GC » (triangle rouge) est déclenché. Lorsque l’événement « Full GC » s’exécute, l’utilisation de la mémoire chute complètement, c’est-à-dire ~ 200 Mo. Veuillez voir la ligne de flèche noire pointillée dans le graphique. Cela indique que l’application est dans un état sain et ne souffre d’aucune sorte de problèmes de mémoire.
2. Modèle de mise en cache lourd
Lorsqu’une application met en cache de nombreux objets en mémoire, les événements « GC » ne pourraient pas supprimer l’utilisation du tas jusqu’en bas du graphique (comme vous l’avez vu dans le précédent « Motif en dents de scie sain ».
Dans la figure 2, vous pouvez remarquer que l’utilisation du tas ne cesse d’augmenter. Lorsqu’il atteint environ 60 Go, l’événement GC (représenté par un petit carré vert dans le graphique) se déclenche. Cependant, ces événements GC ne peuvent pas faire tomber l’utilisation du tas en dessous de ~ 38 Go. Veuillez vous référer à la ligne de flèche noire pointillée dans le graphique. En revanche, dans le précédent « Motif en dents de scie sain », vous pouvez voir que l’utilisation du tas chute jusqu’au bas d’environ 200 Mo. Lorsque vous voyez ce genre de modèle (c’est-à-dire que l’utilisation du tas ne tombe pas jusqu’au fond), cela indique que l’application met en cache beaucoup d’objets en mémoire.
Lorsque vous voyez ce type de modèle, vous souhaiterez peut-être étudier le tas de votre application à l’aide d’outils d’analyse de vidage de tas comme yCrash, HeapHero, Eclipse MAT et déterminer si vous devez mettre en cache ces nombreux objets en mémoire. Plusieurs fois, vous pourriez découvrir des objets inutiles à mettre en cache dans la mémoire.
Voici le rapport d’analyse du journal GC dans le monde réel, qui décrit ce modèle de « mise en cache lourde ».
3. Modèle de fuite de mémoire aiguë
Plusieurs applications souffrent de ce « modèle de fuite de mémoire aiguë ». Lorsqu’une application souffre de ce modèle, l’utilisation du tas augmentera lentement, entraînant finalement OutOfMemoryError.
Dans la figure 3, vous pouvez remarquer que l’événement « Full GC » (triangle rouge) se déclenche lorsque l’utilisation du tas atteint environ 43 Go. Dans le graphique, vous pouvez également observer que la quantité de tas que les événements GC complets pourraient récupérer commence à diminuer sur une période de temps, c’est-à-dire que vous pouvez remarquer que :
une. Lorsque le premier événement Full GC s’est exécuté, l’utilisation du tas est tombée à 22 Go
b. Lorsque le deuxième événement Full GC s’est exécuté, l’utilisation du tas n’est tombée qu’à 25 Go
c. Lors de l’exécution du troisième événement Full GC, l’utilisation du tas n’est tombée qu’à 26 Go
ré. Lorsque l’événement GC complet final s’est exécuté, l’utilisation du tas n’est tombée qu’à 31 Go
Veuillez voir la ligne de flèche noire pointillée dans le graphique. Vous pouvez remarquer que l’utilisation du tas augmente progressivement. Si cette application s’exécute pendant une période prolongée (jours/semaines), elle rencontrera une erreur OutOfMemoryError (veuillez vous référer à la Section #5 – « Schéma de fuite de mémoire »).
Voici le rapport d’analyse du journal GC dans le monde réel, qui décrit ce modèle de « fuite de mémoire aiguë ».
4. Modèle GC complet consécutif
Lorsque le volume de trafic de l’application augmente plus que la JVM ne peut gérer, ce modèle GC complet consécutif deviendra omniprésent.
Dans la figure 4, veuillez vous référer à la flèche noire sur le graphique. De 12 h 02 à 12 h 30 le 6 octobre 2006, les GC complets (c’est-à-dire le « triangle rouge ») sont exécutés consécutivement ; cependant, l’utilisation du tas ne diminue pas pendant cette période. Cela indique que le volume de trafic a augmenté dans l’application au cours de cette période, donc l’application a commencé à générer plus d’objets, et Garbage Collection n’a pas pu suivre le taux de création d’objets. Ainsi, les événements GC ont commencé à s’exécuter consécutivement. Veuillez noter que lorsqu’un événement GC se déroule, il a deux effets secondaires :
une. La consommation du processeur va augmenter (car GC fait une énorme quantité de calculs).
b. L’ensemble de l’application sera mis en pause ; aucun client n’obtiendra de réponse.
Ainsi, au cours de cette période, de 12h02 à 12h30 en octobre 06, étant donné que les événements GC s’exécutent consécutivement, la consommation du processeur de l’application aurait explosé et les clients n’obtiendraient aucune réponse. Lorsque ce type de motif fait surface, vous pouvez le résoudre en utilisant l’une des solutions décrites dans cet article.
Voici le rapport d’analyse du journal GC dans le monde réel, qui décrit ce modèle de « GC complet consécutif ».
5. Modèle de fuite de mémoire
Il s’agit d’un « modèle classique » que vous verrez chaque fois que l’application souffre de problèmes de mémoire. Sur la figure 5, veuillez observer la flèche noire sur le graphique. Vous pouvez remarquer que les événements Full GC (c’est-à-dire ‘triangle rouge’) s’exécutent en permanence. Ce modèle est similaire au modèle précédent ‘Consecutive Full GC’, avec une nette différence. Dans le modèle « GC complet consécutif », l’application récupérerait des exécutions répétées de GC complet et reviendrait à un état de fonctionnement normal, une fois le volume de trafic réduit. Cependant, si l’application rencontre une fuite de mémoire, elle ne récupérera pas, même si le trafic cesse. Le seul moyen de récupérer l’application est de redémarrer l’application. Si l’application est dans cet état, vous pouvez utiliser des outils pour diagnostiquer les fuites de mémoire.
Voici le rapport d’analyse du journal GC dans le monde réel, qui décrit ce modèle de « fuite de mémoire ».
Conclusion
Vous pouvez également envisager d’activer le journal de récupération de place de votre application (car il n’ajoute aucune surcharge mesurable à votre application) et étudier le comportement de la récupération de place. Cela peut révéler des points de vue / perspectives perspicaces sur votre application dont vous n’étiez pas au courant auparavant.