{"id":42,"date":"2007-10-14T16:51:38","date_gmt":"2007-10-14T16:51:38","guid":{"rendered":"http:\/\/blog.milamberspace.net\/index.php\/2007\/10\/14\/sap-memory-analyzer-voila-un-vrai-outil-pour-analyser-des-heap-dump-java-42.html"},"modified":"2007-10-14T18:44:58","modified_gmt":"2007-10-14T18:44:58","slug":"sap-memory-analyzer-voila-un-vrai-outil-pour-analyser-des-heap-dump-java","status":"publish","type":"post","link":"https:\/\/blog.milamberspace.net\/index.php\/2007\/10\/14\/sap-memory-analyzer-voila-un-vrai-outil-pour-analyser-des-heap-dump-java-42.html","title":{"rendered":"SAP Memory Analyzer : voil\u00e0 un vrai outil pour analyser des Heap Dump Java !"},"content":{"rendered":"

Vous avez d\u00e9velopp\u00e9 une application JEE, et depuis son passage en production au moins une fois par jour il y a une erreur Java \u00ab OutOfMemoryError \u00bb. La premi\u00e8re r\u00e9action a \u00e9t\u00e9 de dire : mauvaise configuration de la taille maximale de la JVM… vous avez pr\u00e9conis\u00e9 1Go de Max Heap Size, cela n’a pas fonctionn\u00e9, l’erreur OOME arrive encore… Alors on est pass\u00e9 \u00e0 2Go… Toujours l’erreur d’OOME… Aie, et que faire…<\/p>\n

Quand vous \u00eates \u00e0 ce point, vous pouvez \u00eatre certain que vous avez une fuite de m\u00e9moire (memory leaks) quelque part. Oh, ce n’est pas que vous \u00eates un mauvais d\u00e9veloppeur \ud83d\ude09 et que vous ne savez pas bien gerer la m\u00e9moire, en effet, parfois un probl\u00e8me de fuite de m\u00e9moire peut survenir \u00e0 cause d’une fonctionnalit\u00e9 activ\u00e9e du serveur d’applications de production et qui rentre en \u00ab conflit \u00bb avec une brique de l’application. (Je citerai un exemple v\u00e9cu : le cache (activ\u00e9) JDBC de la source de donn\u00e9es WebSphere 5.1 et un framework maison de mapping O\/R)<\/p>\n

Quand on a un probl\u00e8me d’OutOfMemory, on commence souvent par activer le mode verbeux du Garbage Collector (GC), c’est une tr\u00e8s bonne id\u00e9e, cela permet d’avoir une petite id\u00e9e sur le d\u00e9roulement du probl\u00e8me de m\u00e9moire (on peut utiliser l’outil Extensible Verbose Toolkit d’IBM pour ce travail, cf r\u00e9f\u00e9rences)<\/em>. Cependant c’est insuffisant pour trouver la cause du probl\u00e8me.<\/em> Quelques recherches sur Internet vous apprennent qu’il est possible d’avoir une image de la m\u00e9moire Java avec la g\u00e9n\u00e9ration d’un \u00ab heap dump \u00bb, ensuite il suffit de l’analyser pour trouver la cause de la fuite de m\u00e9moire. Facile \u00e0 \u00e9crire, mais dur \u00e0 faire…<\/p>\n

<\/p>\n

Commen\u00e7ons par la g\u00e9n\u00e9ration du heap dump.<\/strong> La bonne nouvelle, c’est que depuis les versions Java 1.4.2 update 12, Java 5 update 07 et Java 6, la g\u00e9n\u00e9ration de heap dump est \u00ab devenu \u00bb facile. Pour avoir un heap dump automatique d\u00e8s que vous avez une erreur OOME, il faut simplement ajouter ce param\u00e8tre -XX:+HeapDumpOnOutOfMemoryError<\/strong> dans les arguments de la JVM. La mauvaise nouvelle, c’est que pour les versions ant\u00e9rieures, c’est plus difficile d’obtenir un heap dump. Cela d\u00e9pend de l’\u00e9diteur de la JVM que vous utilisez (IBM, BEA, Sun, HP, etc), il faut se reporter sur le site de l’\u00e9diteur pour trouvez la bonne recette…<\/p>\n

Une fois que l’on a trouv\u00e9 le bon param\u00e8tre pour g\u00e9n\u00e9rer son heap dump, il ne reste plus qu’\u00e0 le mettre en production et attendre l’erreur fatal d’OOME. Quand celle-ci arrive, on attend la g\u00e9n\u00e9ration du fichier qui peut prendre plusieurs minutes car le fichier aura la taille de la JVM au moment de l’erreur. Donc si la taille maximum est \u00e0 1Go, le fichier va faire 1Go.<\/p>\n

Maintenant que l’on a son fichier heap dump, il faut l’analyser…<\/strong>et l\u00e0 aussi c’est pas simple. Il existe diff\u00e9rents moyens, allant du mode texte (via Hprof) vers des outils tels que Heap Analyzer de IBM ou bien HAT (ou JHAT maintenant) de Sun. Le gros probl\u00e8me de ses outils, c’est que c’est quasiment impossible d’ouvrir un heap dump d’1Go avec. Vous avez un OutOfMemoryError de l’outil \ud83d\ude09<\/p>\n

La bonne nouvelle c’est que l’\u00e9diteur SAP a pens\u00e9 \u00e0 nous, \u00e0 travers son outil d’analyse Memory Analyzer. Ce dernier est bas\u00e9 sur l’environnement RCP d’Eclipse. Il ouvre sans difficult\u00e9 un heap dump de 1Go, car il analyse le fichier heap dump petit \u00e0 petit et en cr\u00e9ant ses propres fichiers d’index. (Il faut compter environ 1h30 pour ouvrir un fichier 1,2Go sur un portable Vista avec 2Go de RAM, Core 2 Duo 2GHz)<\/em><\/p>\n

Memory Analyzer dispose de nombreuses fonctionnalit\u00e9s, dont l’une qui va nous int\u00e9resser particuli\u00e8rement : la d\u00e9tection de fuite de m\u00e9moire (find memory leaks). De plus il dispose de tutoriaux pour aider \u00e0 l’analyse de fichier heap dump.<\/p>\n

Voici quelques captures d’\u00e9cran qui en diront plus que mes longs discours :<\/p>\n

D\u00e9tails d’un heap dump.<\/strong><\/p>\n

\"D\u00e9tails

\nHistogramme, d\u00e9tails par classe : nombre d’objets, taille la plus petite de l’objet, taille des objets<\/strong><\/p>\n

\"Histogram

\nInspector pour avoir le d\u00e9tail et le contenu d’un objet<\/strong><\/p>\n

\"Inspector\"
<\/p>\n

La d\u00e9tection de fuite de m\u00e9moire<\/strong>, ici un objet d\u00e9tient \u00e0 lui tout seul 657 Mo sur 1024 Mo ! Cela sent le memory leaks…<\/p>\n

\"D\u00e9tection
<\/p>\n

Analyse de la fuite m\u00e9moire<\/strong>, la cause ici semble \u00eatre une liste HashMap de + de 490000 objets.<\/p>\n

\"Analyse

\n
\n[Quelques pointeurs]<\/strong><\/u><\/p>\n