Version imprimable
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 ;)
Bonjour,
La mémoire se libère toute seule.Citation:
comment libérer la memoire??
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 :
Le thread dump sort normalement dans la log de tomcat.Code:kill -3 <pid tomcat>
Le heap dump pour savoir quels objets sont instanciés :
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.Code:jmap -histo <pid tomcat>
PS: si c'est dans un contexte professionnel, n'hésitez pas à vous adresser à des professionnels de la performance Java.
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.
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?
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
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 ;)
d'accord
l'application est deploy une fois, ces log ne s'affiche qu'au demarrage
et puis en fonction des user et du temps qui passe, le tomcat grossit grossit...
donc cela vient de l'application... cela pourrait venir d'ou?
vs connaissez un tuto pour des "fix" rapides?
ca peux venir de n'importe quelle donnée mal gérée par votre application. Le point classique où les données accumulent:
dans des singleton qui stockent les données de chaque user et ne sont pas nettoyé à la fin de la session
dans les sessions elles-même si vous les préservez longtemps (24, voir 48 heure ou plus)
dans des thread local, suivant le meme principe que les singleton.
Les outils comme les profiler java peuvent vous aider à trouver le problème.
tres clairement, il n'y a pas de fix "rapide". c'est un problème de conception ou de développement. Il faut donc les sources pour corriger.
une bonne facon de detecter le code qui pose probleme :
utiliser par exemple http://www.eclipse.org/mat/ (un plugin eclipse qui permet d'ouvrir les fichier de dump de jvm)
et ensuite générer ce dump
soit en ajoutant dans la ligne de conf de la jvm -XX:+HeapDumpOnOutOfMemoryError et attendre le out of memory de l'application
soit avec jmap
(note, le dump a approcimativement la taille de la jvm au moment du plantage, donc faut de la bonne machine pour ouvir le dump)
En général, c'est assez facile de voir quels objets s'accumulent en mémoire et pourquoi.
Ou réduire la taille de la jvm pour accélérer le outofmemory et réduire la taille du dump :pCitation:
Envoyé par lunatix
hihi, effectivement :ccool:Citation:
Envoyé par tchize_
bonjour,
savez-vous comment générer un Head Dump et un Threads dump automatiquement au démarrage du tomcat ? merci d'avance.
No, mais de toutes façons, on en voit pas l'intérêt, il n'y a presque rien qui tourne au démarrage de tomcat :roll:
Pour le thread dump, sous linux, un kill -3
Sous windows, faut démarrer le tomcat en console et faire un ctrl-z.
Pour le heapdump, utiliser jmap.
ok, je vais voir la doc en détail. Merci.
Si tu appele la console du manager de TomCat:
http://localhost:8080/manager/html
Il ya un Button en bas a gauche nommé: Find Leaks, peut etre ca tedera a trouver tes memory leaks:
Note: This diagnostic check will trigger a full garbage collection. Use it with extreme caution on production systems.