Partage de technologie

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Les références:

①Utilisez mtrace pour suivre les fuites de mémoire hors tas de la JVM

②Un cas de dépannage d'utilisation élevée de la mémoire Java

1. Idées d'enquête

Obtenez l'emplacement de la fuite de mémoire (voir les documents de référence ① pour les commandes détaillées)

1. Utilisez jna pour activer mtrace dans le code Java afin de suivre l'allocation de mémoire

2. Utilisez la commande mtrace pour analyser les fichiers journaux et obtenir des points d'appel de fuite de mémoire.

3. arthas vérifie la pile d'appels du point d'appel de fuite de mémoire (vous pouvez utiliser l'adresse du point d'appel directement, aucun nom de fonction n'est requis)

Obtenir le contenu de la fuite de mémoire (voir les documents de référence ② pour les commandes détaillées)

1. Exécutez la commande pmap pour la première fois pour obtenir l'utilisation de la mémoire du processus Java
2. Après un certain temps, la mémoire augmente à nouveau la commande pmap pour obtenir l'utilisation de la mémoire du processus Java.
3. Utilisez l'outil de comparaison de texte pour comparer la sortie des deux commandes pmap avant et après
4. Transcoder pour afficher le contenu des données de la mémoire nouvellement ajoutée

2. Partage de cas

Lors du test d'un service hors ligne, lorsque le QPS est élevé, la mémoire occupée par la zone nio.directbuffer de la machine augmentera soudainement, provoquant l'apparition d'un MOO dans le conteneur.

En utilisant les idées de dépannage ci-dessus, nous avons finalement déterminé que notre framework RPC générait une grande quantité de données dans la zone du tampon direct. En effet, lorsque le QPS est élevé, le nombre de threads de sélection est faible et la capacité de consommation est insuffisante, ce qui entraîne un retard des données de requêtes et de réponses dans la zone du tampon direct.