Discussion :

[Astemius]

Bonjour,

Je travaille sur un batch JAVA traitant des fichiers à volume important en entrée de traitement.
Les fichiers en entrée deviennent de plus en plus gros et j'obtiens des outofmemory error (OutOfMemoryError: Java heap space).

En local, j'ai pu augmenter la taille maximum de la JVM à 2Go via l'argument -Xmx2G
Jusque là rien d'anormal, l'augmentation suffit à "corriger" le problème.

Cependant, sur le serveur, l'erreur est toujours présente.

J'ai donc fait une vérification de la mémoire utilisée par JAVA à l'aide de la méthode getHeapMemoryUsage() de la classe MemoryMXBean.
En local, ça m'indique bien que la mémoire maximum allouée est de 2Go. Cependant, sur le serveur, elle est à 910,25 Mo.

Comment cette différence est possible ? Est-ce qu'il est possible de configurer l'option ou un équivalent de Xmx ailleurs qu'au lancement de l'appli ? Par exemple mettre une taille maximum par instance ?

M'enfin, si vous avez une réponse je suis tout ouïe.

Et accessoirement, vous sauriez comment éviter de lire un fichier texte trop gros d'un seul coup (en gros, couper le readline() effectué pour chaque ligne du fichier afin de le lire en plusieurs fois ou au moins vider la mémoire toutes les 100 000 lignes par exemple) ?

Si c'est pas clair ou qu'il manquerait des infos, n'hésitez pas à demander

Merci !

[tchize_]

Si vous avez cette valeur avant d'avoir le OOM, c'est vraissemblablement que le -Xmx n'a pas été pris en compte. Vérifiez que vous avez bien mi le paramètre au bon endroit. On n'a pas vos scripts sous les yeux.

En cas de doutes, quand le serveur tourne, utilisez (si c'est un serveur unix) ps pour avoir la ligne de commande java utilisée. donnez nous la sortie de votre PS et ce que vous donne maximumHeapSize.

[tchize_]

Et accessoirement, vous sauriez comment éviter de lire un fichier texte trop gros d'un seul coup

Faites vos traitement ligne par ligne. readLine n'est pas en cause. A moins que vous ayez une ligne de texte sans retour à la ligne occupant 500M à elle seule, readline devrais vous convenir. Si vous continuer à consommer la mémoire, c'est que vous stockez ce que vous lisez quelque part en mémoire.

[Astemius]

Alors,

Quelques nouvelles, tu m'as ouvert les yeux. J'ai fait le test en diminuant la taille allouée, pour voir si ça transparaissait et effectivement, rien ne changeait au niveau du heap space affiché.

Alors j'ignore si c'est moi ou un autre développeur mais pour le coup j'ia légèrement honte ^^' Le paramètre -Xmx était simplement situé au mauvais endroit (après l'appel au programme).

Du coup merci beaucoup !

Concernant la consommation de mémoire, effectivement, après une bonne sieste on voit mieux les choses et j'ai deux hashtable qui stockent diverses informations du fichier en entrée (pour chaque ligne et vu que ledit fichier en contient dans 1,5 million, j'imagine que les hashtable souffrent).

Je vais tâcher de voir si y a pas moyen de repenser le traitement différemment.

Merci de l'aide en tout cas.

Edit : Du coup, vu que ce post n'apportera pas grand chose, vaudrait-il pas mieux le supprimer ?

[adiGuba]

Salut,

Alors j'ignore si c'est moi ou un autre développeur mais pour le coup j'ia légèrement honte ^^' Le paramètre -Xmx était simplement situé au mauvais endroit (après l'appel au programme).

Tu le passes comment ???
Il faut qu'il soit présent avant le nom de la classe (ou le nom du jar principal). Sinon c'est un paramètre passé à ton programme et non pas à la JVM.


Et la valeur par défaut du -Xmx peut varier selon plusieurs critères, comme l'OS, la mémoire disponible, le nombre de processeur...

Concernant la consommation de mémoire, effectivement, après une bonne sieste on voit mieux les choses et j'ai deux hashtable qui stockent diverses informations du fichier en entrée (pour chaque ligne et vu que ledit fichier en contient dans 1,5 million, j'imagine que les hashtable souffrent).

Il faudrait avoir un aperçut de ce que tu stockes, et comment tu le fait.




a++

[tchize_]

Edit : Du coup, vu que ce post n'apportera pas grand chose, vaudrait-il pas mieux le supprimer ?

Non, ça me donne des points...

[Astemius]

Oui en fait j'avais ça :
/opt/jdk1.5.0_14/bin/java -cp conf:lib/moniteur.jar fr.moniteur.Main -Xmx2G

Au lieu de ça, qui fonctionne nettement mieux ^^' :
/opt/jdk1.5.0_14/bin/java -Xmx2G -cp conf:lib/moniteur.jar fr.moniteur.Main

Pour le stockage des données, c'est juste un variable.put(toto, titi, tata)
Et j'en ai deux qui se remplissent chacun d'autant de lignes qu'il y a dans le fichier.
Mais en fait, dans mon programme, je pense savoir comment je pourrais éviter les problèmes de mémoire.
Il y a 1,5 million de lignes dans le fichiers, soit 2 hashtable avec 1,5 million d'entrées.
A côté de ça, y a une requête qui me renvoie 16000 enregistrements et pour chaque enregistrement, on rajoute dans un autre fichier (que nous appelleront fichier B) certaines données récupérées à l'aide de la requête et certaines données liées aux hashtables.

Ne serait-il pas plus judicieux de récupérer le résultat de la requête à part, et de parcourir ensuite le fichier contenant les 1,5 million de lignes sans jamais enregistrer les valeurs des lignes dans les hashtables, et donc remplir le fichier B au moment du read ?

Je sais pas si je suis bien clair ^^'

[adiGuba]

Sans code ni explications précises ca risque d'être difficile de t'aider.


Maintenant c'est sûr que si les fichiers sont énormes et que tu stockes tout en mémoire... Ben ca va consommer beaucoup de mémoire !


a++