Discussion :

[StripMat]

Bonjour à tous,

Je développe un traitement qui récupère du contenu XML provenant d'un web service pour construire des objets. J'ai développé tous mes traitements pour une dizaine de documents XML, sauf qu'en réalité, je dois en traiter une cinquantaine, et là j'ai un soucis de mémoire (java.lang.OutOfMemoryError: Java heap space).

Au fur et à mesure des traitements, le processus de ma JVM monte en mémoire jusqu'a plus d'1Go et ça finis toujours par planter...

J'ai bien vu qu'il existait d'autres moyens pour traiter du XML comme SAX seulement j'ai besoins de parcourir les noeuds de mes documents et de vérifier certaines informations avant d'en extraire le contenu, ce que je trouve plus facile à réaliser avec DOM.

Y a t-il une ou des mauvaises pratiques à éviter avec DOM pour ménager la mémoire ?

J'utilise une classe avec des fonctions static pour traiter le XML, je déclare mes InputSource, Document et NodeList comme variables de classe, les instancie au début de mes fonctions et les met à null après les avoirs utilisés.

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
builder = factory.newDocumentBuilder();
is = new InputSource(new StringReader(xml));
doc = builder.parse(is);

Je devrais peut-être faire un vrai singleton ? Et initialiser ces éléments communs à mes fonctions via le getInstance() ?
J'attend vos conseils, je peux présenter du code mais je ne sais pas où commencer

[joel.drigo]

Salut,

Utilise un profiler pour répérer les instances qui stagnent en mémoire, ça te permettra de répérer les fuites de mémoires. S'il n'y en a pas, c'est que manifestement ton programme à besoin de plus de heap et il te suffira de l'augmenter (paramètre -Xmx).

Par ailleurs, d'où viennent les XML ? Je vois que tu utilises un StringReader, donc xml est une String, mais comment est produite cette String ? Si c'est par une lecture de fichier, libères-tu bien les ressources ayant servi à lire les fichiers ?

J'utilise une classe avec des fonctions static pour traiter le XML, je déclare mes InputSource, Document et NodeList comme variables de classe, les instancie au début de mes fonctions et les met à

Pourquoi ne simplement utiliser des variables locales (à la méthode) ?

[StripMat]

Les XML proviennent d'un web service, que je récupère en string comme ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

xmlReponse = EntityUtils.toString(httpResponse.getEntity(), "UTF-8");

Je vais voir de ce côté là, c'est peut-être ma classe Http qui n'est pas bien conçue mais j'en doute. Je vais voir pour utiliser un profiler.

Concernant les variables locales, en fait j'avais conçue ma classe comme ça, mais j'ai pensé que ce serait moins lourd en mémoire de n'utiliser qu'un seul objet déclaré en variable de classe et écrasé à chaque nouvel appel de fonction, mais ça n'est visiblement pas le cas

J'ai essayé d'augmenté la taille du HEAP SPACE à -Xmx1024m mais ça n'est toujours pas suffisant. Je réessaye avec 2048.

Je vais voir aussi si les XML que je cherche à traiter ne sont pas trop volumineux, j'ai lu quelque part qu'il fallait 12x plus de mémoire que la taille du XML à traiter avec DOM. Mais bon, ce qui est étrange c'est que plus j'ai de documents, plus la mémoire monte...

Je test tout ça.

[joel.drigo]

Concernant les variables locales, en fait j'avais conçue ma classe comme ça, mais j'ai pensé que ce serait moins lourd en mémoire de n'utiliser qu'un seul objet déclaré en variable de classe et écrasé à chaque nouvel appel de fonction, mais ça n'est visiblement pas le cas

Strictement aucune différence dans l'occupation mémoire, sauf qu'il faut juste penser à les mettre à null, et que ta méthode est stateless, donc non utilisable en multi-thread.

J'ai essayé d'augmenté la taille du HEAP SPACE à -Xmx1024m mais ça n'est toujours pas suffisant. Je réessaye avec 2048.

Oui, ça fait beaucoup. Il faut voir la taille de tes xml (le nombre de nodes). Déjà, si tu peux traiter le plus gros de tes xml, avec une mémoire donnée, mais que tu ne peux pas en traiter plusieurs d'affilée, c'est plutôt côté fuite de mémoire qu'il faut investiger.

Je vais voir aussi si les XML que je cherche à traiter ne sont pas trop volumineux, j'ai lu quelque part qu'il fallait 12x plus de mémoire que la taille du XML à traiter avec DOM.

Tout dépend déjà de l'API DOM que tu utilises (JavaSE, JDOM...). Bien sûr, utiliser StAX est toujours intéressant avec des gros documents, pas seulement pour l'empreinte mémoire, mais aussi pour les performances (créer plein d'instances de nodes va beaucoup solliciter le GC pour les libérer).

Mais bon, ce qui est étrange c'est que plus j'ai de documents, plus la mémoire monte...

Un signe qui pourrait confirmer la fuite de mémoire (enfin pas forcément, mais combiné avec l'outofmemory, c'est une hypothèse plus que probable).

[StripMat]

Merci beaucoup pour ces indications, j'ai pu installer et réaliser une analyse avec un Profiler, il me reste plus qu'a comprendre ce qu'il me dit. J'en sais un peu plus sur quels éléments porter mon attention.

PS: Je sais pas si l'indication est bonne, mais avec un String.getBytes("utf-8").length / 8 certains de mes XML feraient plus de 3Go mais sa semble passer, en revanche même avec 2Go d'alloués en Heap Space, sa plante encore au bout de X fichiers traités, certains faisant de 3Mo à +3Go

To be continued...

[joel.drigo]

PS: Je sais pas si l'indication est bonne, mais avec un String.getBytes("utf-8").length / 8 certains de mes XML feraient plus de 3Go

Pourquoi le / 8 ?
Attention, en utf-8, un caractère ne donne pas forcément un octet, mais ça peut aller jusqu'à 4 en normalisé (8 en théorie). La plupart des caractères (alphanumérique, symboles standards, y compris de syntaxe xml, les caractères accentués usuels en français), c'est 1 octet, avec certains symboles courants sur 2, et certains caractères spéciaux usuels sur 3 (symbole de l'euro, espaces typographiques...).
Penser au problème de la fuite de mémoire possible avec String.substring (pour les version anté Java7 update 6 de mémoire).

Mais même si tes strings faisait "seulement" 400Mchar, je pense qu'il faudrait envisager un traitement en stream/StAX.

Attention, il y a une taille max de heap (il me semble, 4Gi en 32bits (2Gi sur Windows), 2⁶⁴ en 64bits).