Comment analyser rapidement le fichier tas après que Java l'ait obtenu

Introduction au fichier Heapdump

heap dump : Le fichier de vidage du tas est un fichier binaire qui enregistre l'utilisation des objets dans le tas JVM à un moment donné. Le fichier HeapDump est un instantané de la pile Java à un moment spécifié et est une sorte de fichier image.

Les erreurs de vidage du tas (débordement de mémoire) sont généralement causées par les raisons suivantes :

1) La mémoire JVM est trop petite,

2) Le programme n'est pas strict,

3) Trop de déchets sont générés et ne peuvent pas être recyclé.

Introduction

Après avoir examiné le problème de MOO précédent, un autre service Java a un problème de mémoire cette semaine, le problème n'est pas grave. Il déclenchera uniquement une alarme d'utilisation élevée de la mémoire et ne déclenchera pas le MOO. Le script de vidage a été résumé dans la revue, qui exécutera automatiquement jstack et jmap lorsque l'utilisation du tas est élevée, nous permettant ainsi de conserver avec succès le site problématique.

Vérifiez la distribution d'utilisation du tas

Après avoir découvert le fichier heapdump, je l'ai immédiatement copié sur la machine locale et j'ai utilisé MAT pour l'analyser, comme suit :

Évidemment, il semble qu'une interface ait alloué une très grande chaîne object, une chaîne. L'objet fait environ 200 Mo, alors où est-il alloué ?

Trouver le thread d'allocation d'objets volumineux

Ce comportement d'allocation doit être effectué par un certain thread, et le thread est la racine GC la plus courante, il vous suffit donc de trouver la racine GC de l'objet, comme suit :

Le gros objet est trouvé Le thread d'allocation correspondant est http-nio-8088-exec-6, comme suit :

Afficher la pile de threads

Comment vérifier ce que fait ce thread ? Après avoir tâtonné pendant un moment dans MAT, je n'ai trouvé aucun contenu pertinent. Je me suis rappelé que jstack avait été enregistré dans notre script de dump. Ouvrez-le et jetez un œil, comme suit :

On peut trouver ce fil. fait la sérialisation json, mais j'ai regardé attentivement Après avoir attendu un moment, le contrôleur de l'interface concernée n'a pas été trouvé, car le thread a fini d'exécuter la logique dans le contrôleur et a ensuite renvoyé le gros objet alloué lorsque l'interface a répondu. les données.

Cependant, comme il n'y a pas de code métier dans la pile de threads, il est impossible de localiser quelle interface pose problème. . .

Vérifiez le journal du journal d'accès

Considérant que l'interface d'allocation des objets volumineux sera certainement très lente, je me suis retourné pour vérifier le journal du journal d'accès de Tomcat, comme suit :

Enfin, j'ai trouvé l'interface problématique, qui est utilisé pour interroger les données du produit Oui, lorsque vous entrez 3, tous les produits commençant par 3 seront interrogés et il y a plus de 200 000 données. La résolution du problème est très simple, il suffit d'ajouter une limite et c'est fait.

Révision du processus de dépannage

Cependant, j'ai toujours eu l'habitude, c'est-à-dire qu'après avoir résolu un problème, je réfléchirai à la part de chance impliquée dans le processus de résolution du problème.

Si vous lisez souvent des articles techniques sur le dépannage, vous trouverez de nombreux articles dans lesquels la cause première du problème est soudainement localisée. C'est peut-être parce que vous avez soudainement découvert un indice, ou que vous pouvez le voir en regardant le code, ou encore. vous pouvez le deviner. Il y a un problème quelque part. Je pense que ce processus de dépannage implique beaucoup de chance. J'espère que le problème pourra être résolu étape par étape grâce à des années d'accumulation de bases théoriques et d'utilisation compétente d'outils de diagnostic.

Le problème ci-dessus peut être localisé via le journal d'accès, ce qui a une certaine chance, car le problème de mémoire cette fois n'est pas extrême. Si le volume de requêtes de cette interface est important, plusieurs FGC seront déclenchés instantanément, ce qui ralentira. en bas d'autres interfaces. Il n'y a aucun moyen de savoir quelle interface est à l'origine du problème !

Je pense, en théorie, qu'il devrait y avoir une pile de threads et des paramètres sur la pile de threads dans le fichier de tas Java. Parce que les threads sont des objets et que les paramètres sont également des objets, ils devraient tous être dans le tas, j'ai donc trouvé du temps libre. , j'explore à nouveau l'outil MAT.

MAT View Thread Stack

Après avoir tâtonné pendant un moment, j'ai trouvé un bouton pour afficher les informations sur le fil, comme suit :

Trouvez le fil http-nio-8088-exec-6 mentionné plus tôt et développez-le, vous pouvez trouver la pile de threads et les paramètres sur la pile, comme suit :

Ensuite, vous trouvez l'objet paramètre Request de la requête. Après avoir développé l'objet Request plusieurs fois, vous pouvez trouver les informations sur l'URL de l'interface, comme suit. :

VisualVM View Thread Stack

Étant donné que de nombreux étudiants sont habitués à utiliser VisualVM pour analyser le tas, voici comment utiliser VisualVM.

Tout d'abord, chargez le fichier heapdump, comme suit :

Ensuite, sélectionnez l'objet correspondant, cliquez avec le bouton droit et sélectionnez Sélectionner dans les fils de discussion, comme suit :

Après avoir localisé la pile de fils de discussion, recherchez l'objet Request que vous souhaitez afficher, cliquez pour entrer, comme suit :

De même, développez l'objet Request. Après cela, vous pouvez trouver les informations sur l'URL comme suit :

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!