Discussion :

[Oui-Oui MB]

Bonjour,

je travaille sur une grosse application Web qui tourne avec Tomcat 5.5.12. Nous avons notre propre système de template et il y a donc une classe qui se charge de les remplir.

Lorsque nous voulons générer une très grosse page (genre un listing avec plus de 1000 résultats, et c'est pas si rare), la mémoire grimpe jusqu'à des 100 voir 150 mo et le CPU est à 98 - 99% (il doit s'agir du Garbage Collector).

Après un petit dépoussierage du code (la classe utilisait des String partout tout le temps alors j'ai mis des StringBuffer), rien n'a changé. Pourtant, je vide les StringBuffer, je le met même à null à la fin pour que le GC fasse son job proprement mais la mémoire gonfle toujours.

Ma supposition est que Tomcat garde dans une sorte de cache les résultats des requêtes et que le GC ne peut donc pas libérer ces ressources...

Est-ce que quelqu'un à déja eu un pareil problème ? Quelqu'un sait-il si ma supposition semble être bonne ? Dans ce cas, y a t'il moyen d'empêcer Tomcat d'utiliser un cache ?

[zekey]

Je pense que c'est lié au design de ton application, il nous arrivent de balancé des liste avec 9999 lignes et plusieur clients sans problème.

[Oui-Oui MB]

Et dans le cas ou tu envoie autant de ligne, tu envoie le résultat ligne par ligne vers le client ou alors tout d'un bloc ?

[zekey]

Voila le design

JSP // List un bean contenant une liste paginable ou non c'est 9000 elems d'un coup ou par page de 20 par exemple
Action // Appel le métier et efectue les formatages conversion métier-pésentation et coupe en page si nécéssaire
Metier // Appel le DAO en une fois pour pouvoir fermer resulset et sessions
DAO // Effefctue le select

Mais en gros plusieurs remarques:
-Le bean list est en session pas en request (a cause du multipages)
-Tous les resultsets, connection, sessions (sauf si pooling) et autres sont refermés apres chaque query (pas de paging au niveau sql).
- Tomcat 5.0.28
- Mémoire 256M
- 800 utilisateurs / 20 concurrents

J'ai aussi eu des problèmes de mémoire et c'etait....la partie DAO qui foirait, resultset et compagnie.
Je te recommande avant d'y passer la semaine de recourir à un profiler.
Il en existe des payants mais aussi des gratuits, il suffit de chercher sur sourceforge.

[Oui-Oui MB]

Merci bien, je vais un peu fouiller le sujet mais recentrer un peu plus sur le DAO...

[jsl1]

Sous Tomcat, édite le fichier catalina.bat et ajoute :

Code :

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

set JAVA_OPTS="-verbose:gc"

Cela te permet de suivre les passages du GC dans la console Tomcat.
Quand la quantité de mémoire utilisée par ton appli atteind la quantité max allouée à la JVM, 2 possibilités :
- le GC passe, la mémoire est relachée
- exception OutOfMemory, dans ce cas là 2 solutions :
* tu as une memory leak (des objets java non utilisés sont gardés en memoire)
* la taille de la JVM n'est pas dimensionnée correctement pour ton application, il faut donc faire des tests de charge pour régler ce pb.

hope it helps
++
jsl1