Comment résoudre le problème des GC complets fréquents en raison d'une utilisation anormale de la mémoire Java

Problème de système

L'inspection quotidienne a révélé que des gc complets fréquents

phénomène sont apparus sur la ligne de candidature

Des gc complets fréquents sont apparus sur la ligne de candidature

Processus de dépannage

Analyser le vidage

Extraire le fichier de vidage : Interlude : Si vous spécifiez : live lors du dumping, la jvm effectuera un gc complet avant le dumping, et le dump full gc sera imprimé dans le journal gc. Ce type de dépannage pour les conditions de mémoire anormales en ligne causées par des fuites non-mémoire entraînera des désagréments. menant à Nous avons vidé plusieurs fois.

Analysez le fichier de vidage :

a. On constate qu'un grand nombre de tableaux long[] occupent l'espace maximum, et il y a des anomalies

b. Vérifiez le nœud racine gc et constatez que la plupart d'entre eux. ces données long[] sont utilisées par org.HdrHistogram, chaque objet Histogram contiendra un long[] de taille 2048

c En regardant le nombre d'instances d'Histogram, il y en a en fait 50 000 par rapport à la pile normale. projets, c'est environ 100 fois

d . Voici un autre épisode J'utilisais l'analyse mat au début, mais le rapport généré par mat est plus utile pour analyser les fuites. Pour analyser la mémoire anormale, ce n'est pas le cas. aussi utile que jvisualvm.exe et idea profiler

Dépanner la cause

Vous pouvez le démarrer localement Pour reproduire l'utilisation de la mémoire de cette classe, j'ai démarré un service local avec la mémoire normale et l'application problématique, et analysé la comparaison de la mémoire. le profileur d'idée est utilisé ici, ce qui est très pratique. Trouvez la différence :

Comparez l'application normale, il a été constaté que la référence de l'application anormale contient une référence anormale de

weight rx.internal. Operators.OnSubscribeReduceSeed$ReduceSeedSubscriber. On soupçonne que cette référence anormale empêche le recyclage de ces instances dans la nouvelle génération mais s'accumule dans l'ancienne génération. Raisons des différences de dépannage complètes :
Examinez brièvement les éléments pertinents. code, mais je n'ai pas pu voir la raison. Comparaison de débogage directe

Le système a entré le code correspondant et a ajouté une référence à l'histogramme, mais l'application normale ne l'a pas fait

Mais je ne peux pas dire pourquoi simplement en regardant. À ce moment-là, j'ai prêté attention au pool de threads dans le coin inférieur gauche. Ce pool de threads est assez étrange. C'est le pool de threads de Metric qui est utilisé par Hystrix pour compter les indicateurs pertinents pour son propre tableau de bord ou ses utilisateurs. . Venez le comprendre pour comprendre la fonction des paramètres et des indicateurs liés au disjoncteur du système. Regardez à nouveau la pile, la logique pour arriver ici est

Ce flux est utilisé pour compter les indicateurs du système par unité de temps, provoquant Hystrix. pour utiliser le long tableau d'histogramme. Obtenir un effet similaire à une fenêtre coulissante pour compter les indicateurs dans une unité de temps
L'histogramme lui-même est utilisé par Hystrix pour implémenter une fonction similaire à un seau + une fenêtre coulissante pour compter le trafic dans une unité de temps. , parce que les paramètres de l'indicateur sont activés, hystrix doit effectuer des statistiques sur une période plus longue. Pour les indicateurs compris dans la plage, un nouvel objet contient plus de références d'histogramme (unité de temps) pour l'agrégation, car ces références sont utilisées pour compter une durée plus longue. périodes de plage, elles seront anciennes car les références sont conservées pendant une longue période. Mais l'essence n'est pas une fuite de mémoire, elle peut donc être recyclée après chaque gc complet

Résoudre le problème

Voir les différences ci-dessus et le pool de threads bizarre, la première réaction est de désactiver la métrique pour que l'application n'aille pas dans cette logique pour augmenter. Pour citer, consultez la documentation officielle Cette configuration est activée par défaut, et confirmez que cette fonction n'affecte que l'indicateur. statistiques et n'affecte pas le fonctionnement du disjoncteur lui-même. Utilisez la configuration hystrix.metrics.enabled=false pour le désactiver Après avoir ajouté la configuration, vérifiez et visualisez la pile, la référence est revenue à la normale et le système ne l'a pas fait. ajoutez plus d'instances d'histogramme après un certain temps. Après avoir observé pendant un certain temps après sa mise en ligne, le problème complet de gc a effectivement été résolu

La cause profonde

Après la découverte et la vérification de la solution à l'époque, je n'ai pas Nous n'avons pas le temps d'étudier la raison pour laquelle la configuration par défaut de hystrix.metrics.enabled est vraie, mais d'autres applications n'ont pas ce problème gc complet. Après l'avoir résolu en premier, nous continuerons à suivre et à enquêter sur la cause première pour en empêcher d'autres. projets d'avoir le même problème.

Découvert avant Le pool de threads suspect est HystrixMetricsPoller Après vérification, le pool de threads est ouvert par la classe HystrixMetricsPollerConfiguration

Il est principalement ouvert par hystrix.metrics.enabled. la valeur par défaut est true. Pourquoi les autres projets ne sont-ils pas activés ?

J'ai recherché le code source et j'ai constaté que l'activation de cette classe est liée à une annotation

Après avoir comparé le code, il s'avère que seule l'application anormale utilise cette annotation. Le but de cette annotation est de tourner. sur le disjoncteur

Mais après recherches, j'ai découvert que, sans utiliser cette annotation, des fonctions telles que les disjoncteurs sont toujours disponibles. La raison en est qu'après la version spring-cloud, spring utilise hystrix pour encapsuler openfeign afin d'utiliser des disjoncteurs au lieu de. intégrant l'ensemble du système hystrix. Peut-être que spring-cloud a également découvert la mémoire hystrix. Problèmes d'utilisation

Donc, dans les versions supérieures (au moins notre version), feign allume et éteint le disjoncteur via feign.hystrix.enabled (si cet interrupteur est activé). désactivé, le simple fait d'ajouter @EnableCircuitBreaker pour annoter le disjoncteur ne prendra pas effet)

En fait, dans les versions supérieures de spring-cloud, l'annotation @EnableCircuitBreaker a été marquée comme obsolète, mais peut-être parce que nous sommes une version intermédiaire, il y a situations où il n'est pas marqué comme obsolète et n'est en fait d'aucune utilité

En bref, la fonction de disjoncteur de feign est uniquement contrôlée par feign.hystrix.enabled L'ajout de l'annotation @EnableCircuitBreaker activera uniquement tous les autres indicateurs et autres fonctions de Hystrix

.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!