Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

[Weblogic/SOA] Détecter les fuites mémoire

Partager sur linkedin
Partager sur twitter
Partager sur facebook

Introduction

L’activité d’une plateforme SOA pilotée par un serveur d’applications tel que Weblogic sollicite naturellement une quantité non négligeable de la mémoire du (ou des, en environnement clusterisé) serveur(s) qu’elle gère.
Cette mémoire croit naturellement avec le nombre (généralement croissant) de composants (métier) qui sont déployés, et de leur activité respective.
Ces composants métier peuvent avoir été implémentés avant que la plateforme SOA ne soit de plus en plus sollicitée (car ceci est la raison d’être d’une architecture SOA : nous capitalisons sur son existence en lui faisant prendre en charge toujours plus de services et de flux de données).
De ce fait, les éventuelles imperfections d’implémentation peuvent n’être détectées qu’une fois le volume d’activité arrivé à maturité.
Une fuite mémoire pratiquement imperceptible à l’origine du projet peut devenir critique voire catastrophique une fois que le système d’informations tourne à plein régime.
Nous allons voir comment détecter/anticiper ce genre de problème.

VisualVM

VisualVM est un outil de supervision d’applications Java en cours d’exécution dans une machine virtuelle Java (JVM).
Vous trouverez l’exécutable de VisualVM au sein de votre JDK ici : <JAVA_HOME>/bin/jvisualvm.exe.
Une fois connecté à votre environnement Weblogic, sélectionnez le profil « Memory » comme ci-dessous :
visualvm1
Vous y trouverez tous les objets actuellement instanciés.
Ensuite vous pouvez créer une capture (snapshot) dans le but d’effectuer une analyse à posteriori :
visualvm2
Ouvrez la capture, cliquez droit sur une classe, et sélectionnez « Show Allocations Stack Traces » :
visualvm3
Vous pourrez alors voir apparaître l’arborescence de la pile d’appels de tous les objets instanciés, ce qui vous permettra remonter vers la source du problème, grâce au détail des méthodes successivement invoquées, ainsi que leurs statistiques associées :
visualvm4

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.