Discussion :

[crofteur]

Bonjour,

j'ai un gros soucis de performance sur une application...

j'ai un tomcat 6 sur un server dédié, il n'y a qu'une application dessus.

je deploye le war, demarré l'applic, elle se lance en qques secondes : ressource memoire du tomcat : ~100mo
apres 2 jours d'utilisations : tomcat 1,6go :o et l'applic met plus de 10min à se lancer...

app : java flex

comment libérer la memoire??

merci

[Invité]

Bonjour,

comment libérer la memoire??

La mémoire se libère toute seule.
La JVM consomme de la mémoire dès lors qu'elle a de la place pour travailler.
Ensuite quand elle n'a plus de place, elle nettoie les objets devenus inutiles (Garbage Collector).

La taille de la mémoire n'est de toute manière pas directement responsable des ralentissements observés sur le fonctionnement de l'application. Mais elle peut être indirectement responsable: si des FULL GC se déclenchent très fréquemment et ne parviennent jamais à libérer un espace assez confortable.
Les logs tomcat devraient donner des informations sur le comportement du GC.

Par ailleurs, il faudrait faire un Thread Dump et un Heap Dump pour comprendre un peu mieux ce qui dérappe.

Le Thread dump pour savoir ce qui tourne dans la JVM :

Code :

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

kill -3 <pid tomcat>

Le thread dump sort normalement dans la log de tomcat.

Le heap dump pour savoir quels objets sont instanciés :

Code :

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

jmap -histo <pid tomcat>

Il est possible d'aller plus loin en terme d'analyse, mais déjà le comportement du GC et ces deux Dumps peuvent aider pour cerner le problème.

PS: si c'est dans un contexte professionnel, n'hésitez pas à vous adresser à des professionnels de la performance Java.

[crofteur]

Merci je vais un peu regarder à ceci.

Sinon j'ai remarqué ceci ds les log catalina...


GRAVE: The web application ************ registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
07-janv.-2011 21:33:36 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
GRAVE: The web application ************ registered the JBDC driver [net.sourceforge.jtds.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
07-janv.-2011 21:33:36 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
GRAVE: The web application ************ appears to have started a thread named [Thread-2] but has failed to stop it. This is very likely to create a memory leak.
07-janv.-2011 21:33:36 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
GRAVE: The web application ************ appears to have started a thread named [Timer-0] but has failed to stop it. This is very likely to create a memory leak.
07-janv.-2011 21:33:36 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
GRAVE: The web application ************ appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak.
07-janv.-2011 21:33:36 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
GRAVE: The web application ************ created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@820846]) and a value of type [flex.messaging.config.SystemSettings] (value [flex.messaging.config.SystemSettings@ed3e63]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
07-janv.-2011 21:33:36 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
GRAVE: The web application ************ created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@19b0124]) and a value of type [flex.messaging.MessageBroker] (value [flex.messaging.MessageBroker@167f4bf]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
07-janv.-2011 21:33:36 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
GRAVE: The web application ************ created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1f53293]) and a value of type [org.springframework.flex.core.MessageBrokerFactoryBean.DelegatingServletConfig] (value [org.springframework.flex.core.MessageBrokerFactoryBean$DelegatingServletConfig@cb800f]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

[tchize_]

cherchez pas plus loin, votre application crée de classloader leak durant ses undeploy. C'est assez courant. Il y a un raison particulière pour faire des redémarrages régulier de votre application web? Et vu qu'elle est seule, il y a une raison particulière pour ne pas redémarrer aussi le tomcat?

[crofteur]

disons que c'est assez contraignant de devoir redemarrer le tomcat tous les 2 jours

"c'est assez courant" mais normal? cmt le resoudre?

disons qu'il y a bcp d'utilisateur de lieu different qui y accedent, donc ils ouvrent une nouvelle session a chaque fois...
a chaque launch de l'app, cela fait environ +30mo au tomcat

[tchize_]

non d'après vos log vous faites du deploy/undeploy, et c'est à ce moment là que vous avez du memory leak!


Si ce n'est pas le cas (et que ce log viens juste d'un arrêt de tomcat), il n'est alors en aucun cas lié à votre perte de mémoire. Si tomcat se prend +30M à chaque nouvel utilistaeur, la cause est à aller chercher dans le design de votre application. Pareil si les données restent même après destruction de la session.


donc pour faire clair: est-ce que vous faites des démarrage/arrêt régulier de votre session? Si oui, redémarrer tomcat en même temps, ce n'est pas contraignant. Si non, c'est votre application qui a été développée avec les pieds