Tutoriel pour activer les logs GC d'une JVM sans redémarrage avec l'aide d'Apache JMeter

Nous verrons comment associer la puissance de JMeter, de JMX et de Groovy afin d'activer les logs GC sur une application en cours d'exécution.

Pour réagir à ce tutoriel, un espace de dialogue vous est proposé sur le forum 1 commentaire Donner une note à l'article (5).

Article lu   fois.

L'auteur

Site personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

Votre application vient enfin d'être mise en production après la phase de tests (fonctionnel, etc.). Les tests ont été concluants, vous êtes donc serein.

Trois jours après, une alerte remonte sur la consommation mémoire élevée. Pour résoudre ce problème, vous faites appel à un spécialiste qui vous demande les logs GC.

Malheureusement ils n'ont pas été activés et il n'est pas possible d'arrêter le serveur pour ajouter les paramètres à la JVM (en particulier pour XX:+PrintGCDetails) qui nous permettraient d'avoir ces fameux logs.

II. La solution : JMX

Heureusement, dans le monde Java, il existe JMX qui nous permet de superviser/récupérer des métriques et de modifier certains d'entre eux.

Le MBean JMX qui nous intéresse est com.sun.management:type=HotSpotDiagnostic et en particulier la fonction setVMOption().

Image non disponible

Cette fonction va nous permettre d'activer le paramètre XX:+PrintGCDetails sans avoir à redémarrer notre JVM.

Activons-le avec setVMOption (PrintGCDetails, true).

Image non disponible

Dès l'activation, les logs GC apparaissent dans la sortie standard du programme.

[GC [DefNew: 14971K->865K(15808K), 0.0027772 secs] 38315K->24285K(50768K), 0.0221390 secs] [Times: user=0.00 sys=0.00, real=0.02 secs]

III. OK, mais quid de l'overhead ?

Nous avons enfin un moyen d'activer les logs GC, mais quelqu'un de l'équipe demande si l'overhead de l'activation ne risque pas d'aggraver le problème ou d'en créer des nouveaux.

Comme nous l'avons vu sur ce précédent article, un overhead trop important peut modifier le comportement (mémoire, etc.) de l'application.

Un POC (Proof Of Concept) afin de tester l'overhead sur la préproduction est décidé. Afin de le réaliser, on décide d'utiliser Apache JMeter associé au langage de script Groovy.

Cette solution est choisie, car l'intégration entre Groovy & JMX d'un côté et Groovy & Apache JMeter d'un autre côté est très simple à mettre en œuvre.

Commençons par notre script JMX qui va activer le paramètre PrintGCDetails.

L'intégration entre Apache JMeter et Groovy se fera à l'aide de l'élément Echantillon JSR223.

Image non disponible

Cet élément permet d'exécuter des scripts dans différents langages dans notre scénario Apache JMeter.

Par défaut, Apache JMeter n'intègre pas Groovy et donc, il faut installer l'implémentation Groovy (un fichier .jar) dans le CLASSPATH (sous-répertoire lib d'Apache JMeter).

Pour cela, il suffit de mettre le fichier groovy-all-*.*.*.jar livré avec Groovy dans le sous-répertoire lib d'Apache JMeter.

Après un redémarrage d'Apache JMeter, on a accès à Groovy avec l'élément Echantillon JSR223.

Image non disponible

Il nous reste à copier le script dans le champ prévu à cet effet.

Image non disponible

Et voilà, on peut maintenant commencer notre POC.

Partons de l'exemple réalisé lors de la présentation de JMeter avec l'application PetClinic.

Le principe est d'avoir un autre groupe d'unités qui va exécuter une seule fois notre élément Echantillon JSR223 après plusieurs minutes de test (nombre à définir en fonction du temps de chauffe de l'application).

Par exemple, activons les logs GC après 20 minutes de test.

Dans un premier temps on fait durer notre test pendant 30 minutes.

Image non disponible

Ajoutons notre groupe d'unités qui va activer nos logs GC 20 minutes après le début du test.

Image non disponible
Image non disponible

Exécutons notre test.

Pour nos résultats, on va comparer les temps de réponse sur la période entre 10 et 20 minutes et la période après l'activation des logs GC (entre 20 et 30 minutes).

Comme on peut le voir sur le graphique, dans ce cas-là (avec cette application, cette charge cible, etc.), l'impact est négligeable.

Image non disponible

Rassurés par les résultats, l'activation des logs GC est réalisée en production sans redémarrage afin de traiter le problème de mémoire.

IV. Conclusion et remerciements

Comme on a pu le voir, les possibilités offertes par JMX sont énormes. Possibilités que l'on peut exploiter facilement avec Apache JMeter et Groovy.

Ce que l'on a fait en activant les logs GC d'une application sans la redémarrer afin de calculer l'overhead de l'activation.

Il y a encore de nombreuses choses que l'on peut faire avec JMX que je vous laisse tester, car la pratique est essentielle dans notre métier.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2015 Antonio Gomes Rodrigues. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.