Session du Ch'ti JUG sur Java Performance par K. Pepperdine avec OpenSagres

Mercredi 25 avril 2012, le Ch'ti JUG nous a présenté une session sur la performance Java avec la participation d'OpenSagres (prononcer open saglech c'est du portugais) et présenté par Kirk Pepperdine, voici ce que j'y ai appris.

Does your GC log file speaks to you ?

La performance en Java est un long sujet, et pas qu'en Java, c'est d'ailleurs un sujet récurent dans le monde de l'informatique. La présentation de Kirk fut surtout focalisée sur la gestion mémoire de la machine virtuelle Java (JVM) est principalement sur l'analyse de ce que fait le très fameux ramasse miette (GC pour garbage collector).

Petit cours de rattrapage sur le Tas

Avant de rentrer dans le vif du sujet, nous avons eu un rappel sur le fonctionnement de la mémoire de la JVM et quelque notion sur la théorie des objets qui naissent et meurent dans un délai assez court.

Il faut collectionner les fichier de log du GC!

Kirk nous a montré qu'il était possible, lors du lancement d'un programme Java, de faire cracher le morceau à la JVM sur le comportement du Garbage Collector.

$> java -verbose:gc -Xloggc:<file>...

Il nous confiera même qu'il a développé une forme de trouble obsessionnel compulsif consistant à accumuler ces fichiers de traces qu'il a par milliers. Bref, il nous a non seulement appris à produire ce fichier, mais également à le lire. Effectivement on y trouve une foultitude d'informations qu'il convient de lire avec patience afin d'en déduire un paramétrage idéale.

Car c'est bien la la meilleure leçons à retenir : Il n'y a pas de réglage optimal universel du garbage collector Toutes les possibilités offertes sont là pour permettre une meilleure utilisation dans certaines conditions, sinon pourquoi tant de façon de faire la même chose si seulement une d'entre elle était efficace dans tous les cas ? Le choix de l'optimisation revient à concilier le temps perdu lors de l'analyse de la mémoire avec la quantité de mémoire à traiter. Trop de mémoire pour le tas n'est pas toujours une bonne idée. Fixer la taille initiale à l'identique de la taille maximale est une grossière erreur. Les différents types de GC ont tous leurs avantages et leurs inconvénients.

Des outils existent

Le comportement de la mémoire peut en outre être observer en temps réel en complément des GC logfile via des outils comme JConsole ou encore Visual VM. En outre, un outil très complet, Visual GC, issu de jvmstat et téléchargeable gratuitement permet de voir évoluer les différentes strates de la mémoire en temps réel.

Conclusion

Cette session, bien qu'en anglais, fut très enrichissante, et dès le lendemain j'ai pu mettre en pratique ces connaissances et affiner les réglages mémoire pour faire passer la consommation mémoire d'un batch sur lequel je travaillais, de 250Mo à 64Mo (en fait 25Mo le reste de la HEAP de servant alors à rien).

Je retiens surtout qu'il ne faut pas faire d'optimisation prématurée : Il faut constater le phénomène, tenter de l'expliquer, effectuer un petit changement de configuration et refaire les mesures. Toutes les exemples montrés n'ont jamais remis directement en cause le code des applications (sauf celui qui montré les appels à System.gc()).

Une très bonne séance qui a su donner des fruits très tôt dans mon cas, merci au Ch'ti JUG(@chtijug), merci à Pascal Leclerc (@pascalleclercq) et OpenSagres et encore merci à Kirk Pepperdine(@javaperftuning).