J'ai une webApp Java en cours d'exécution, que je surveillais avec VisualvM .
Voici le graphique du tas:
L'a été testé avec deux séries de demandes, une à 3 h 20 et l'autre à 4:40 environ (ils sont représentés dans le graphique comme seuls deux pics).
Ma question est la suivante: cela signifie-t-il que j'ai une fuite de mémoire? Je suis inquiet de la partie centrale où, bien que le GC fonctionne, le tas reste en 250 Mo tout le temps.
Merci beaucoup pour vos idées. 
5 Réponses :
Vous dites qu'il n'y avait pas de demandes avant 3h20? Si oui, que je dirais que je ne vois aucune preuve d'une fuite.
Je ne connais pas votre application, mais c'est typique (basée sur l'architecture / design) pour certains objets qui traînent pour la vie de la JVM pour devenir initialisé lorsque l'application est utilisée pour la première fois.
Qu'est-ce que JRE utilisez-vous? Quels paramètres pertinents sur le tas / GC sont transmis à l'application?
Le pic n'est pas mauvais (s'il y avait plus de TOO pour le serveur, il est logique que le sommet augmente). Mais qu'est-ce qui ne cherche pas si bon, que le niveau après 4:40 (lorsque la charge est à nouveau faible) est plus élevé au fur et à mesure que le niveau avant la charge a augmenté. Mais il n'a pas besoin d'être ...
Vous devez maintenant examiner plus de détails, quels objets ou graphiques d'objet sont conservés dans le tas. Donc, le même test est-il à nouveau exécuté, y compris (avec profileur):
Vous devez maintenant analyser les diffs et si vous voyez des objets étranges, qui auraient dû être gaspillés.
La première demande à 3 h 20 a entraîné la maintenue de la mémoire, mais remarquez que la GCS après la deuxième demande a recueilli la majeure partie de celle-ci. De plus, je pense que le major GC n'a été effectué qu'après la deuxième demande à 4h40.
On dirait qu'il n'y a pas de fuite. Ma théorie est que la demande à 3 h 20 a causé la jeune génération à se remplir et la GC mineure résultante a promu certains objets à la génération plus âgée. Le prochain grand GC, causé par la demande à 4h40, nettoya la plupart de ceux-ci.
Vous pouvez vérifier cela à l'aide d'un profileur pour marquer le tas avant d'émettre la même demande que celle à 3 h 20, forçant une GC complète, puis en train de vérifier quels objets persistent. Je ne sais pas si Visualvm vous permet (1) marquer le tas et (2) forcer une GC complète, mais optimiser l'habitude de le faire.
Merci beaucoup binil. Pourriez-vous me signaler une bonne documentation de référence pour rattraper tous ces concepts? (Jeune génération, génération plus âgée, différents types de gifx de GC, etc.)
En effet, un autre examen avec le plug-in VisualGC a montré que des objets ont été favorisés dans l'autre partie du tas.
Jvisalvm vous permet de forcer une collection à ordures.
Essayez d'utiliser cela pour voir ce qui se passe.
Est-ce que cela le force réellement, ou appelle-t-il system.gc ()?
Je crois que ça le force. Peut-être que c'est Sun JVM seulement.
Il appelle en fait system.gc () il ne force rien.
Que voulez-vous dire par fuite de mémoire ici? Je ne pense pas que tout bon JVM MiseAiTon comme Sun aurait un bug aussi fou. Le mot de fuite de mémoire est idéalement utilisé lorsque vous n'avez pas de référence à un emplacement de mémoire (zombie) ou que vous n'avez aucune possibilité de la récupérer. Si vous avez des pratiques de programmation incorrectes dans lesquelles vous détenez une référence à des objets qui ne sont plus utilisés et qu'ils sont plus importants (viepan), vous consommez plus de mémoire ne donnant pas à la GC une option de la récupérer.
Une taille d'échantillon de 2 ne donne pas vraiment assez d'informations pour déclarer une fuite. Oui, on pourrait être caché dans ce graphique: la taille allouée à la droite est plus grande que celle à gauche. Ou comme il pourrait, comme Binil mentionné, il suffit d'être que certains objets ont été promus dans la génération titulaire et que vous n'avez pas eu de GC majeur.
Vraiment, le seul moyen de déterminer si vous avez une fuite consiste à comparer le nombre d'objets vivants retenus au fil du temps. J'ai posté un article (ici) ( kdgregory.com/index.php? Page = Java.outofMemory ) qui parle de la manière d'analyser un dépotoir de tas.