Bonjour, Les robots parcourant les sites ou même les visiteurs ne pourraient-ils pas avoir une session minimaliste . Je pense surtout au « guest » qui na pas vraiment besoin dune session ( ou alors faire en sorte que sa session soit effectivement très courte).
Serait-il possible alors de spécifier une durée de session pour le guest ?(par exemple via jParams.getsessionState().setMaxInactiveInterval(600) pout 10 minutes) Cordialement, Alexis Annosse Smile - Motoristes Internet <http://www.Smile.fr> www.Smile.fr Tél : 01 41 40 88 02 _____ De : Stéphane Croisier [mailto:[EMAIL PROTECTED] Envoyé : vendredi 22 décembre 2006 14:30 À : [email protected] Objet : RE: Problème de mémoire, consommation du cache de Ja hia Salut Fabrice, Malheureusement les JVM 1.4 ne donnent pas bcp d'informations sur les OOM. Nous avons remarqué récemment que les sessions consommaient beaucoup de RAM et que, par défaut, elles étaient de 30 minutes... ce qui fait beaucoup pour un site web par exemple avec des utilisateurs qui surfent le site seulement pendant quelques secondes avant de "zapper" ailleurs. Vous pouvez donc tenter de diminuer cette durée des sessions (bon après cela risque de poser un problème pour les éditeurs qui risque de perdre le contenu de leur engine s'ils éditent un rich text pendant plus de 10 minutes....ou alors il faudrait des sessions différentes entre le serveur d'édition et le serveur de consultation et/ou entre les users anonymous et les autres...) Sinon il existe des outils pour Tomcat style LambdaProbe qui est vraiment excellent pour monitorer votre Tomcat et/ou JVM afin de tenter d'obtenir plus d'informations sur ce qui consomment temps de ram. Certes avec une JVM 1.4 les informations seront plus limitées qu'avec une 1.5 ou un 1.6... Serge a écrit un peu de doc d'ailleurs à ce sujet: Monitoring server memory, CPU usage, threads and sessions Unfortunately though, JAMon will not give you more detailed information about the status of sessions, memory, threads, etc. For this you can install different tools on your server to help you out. First of all, there is MessAdmin <http://messadmin.sourceforge.net/> , which is quite minimal in functionality, but allows you to see and track session data. You can also send messages to users, for example to inform them that a maintenance will take place. MessAdmin does all this through usages of filters, so not only is it quite transparent to install, but it is also portable to a lot of application servers. Some of the tools available in JDK 5 and 6 that are very interesting are JConsole <http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html> or VisualGC <http://java.sun.com/performance/jvmstat/visualgc.html> One of the best tools, but is Tomcat specific, is LambdaProbe <http://www.lambdaprobe.org/d/index.htm> . If you activate Tomcat's JMX interfaces, you can even monitor garbage collection internal spaces, such as PermGen, Eden, etc.. Monitoring Tomcat and Jahia through LambdaProbe If you want to monitor Jahia's execution with LambdaProbe <http://www.lambdaprobe.org/d/index.htm> or JConsole <http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html> , modify your Tomcat's catalina.bat (catalina.sh) script to add the following : -Dcom.sun.management.jmxremote to the line : set CATALINA_OPTS=%CATALINA_OPTS% -Dsun.io.useCanonCaches=false -Xms64m -Xmx1024m -XX:MaxPermSize=128m -server -Dhibernate.jdbc.use_streams_for_binary You can then view internal thread and memory processing of your server. If you want to configure remote access monitoring, this is quite more complicated, and the best thing is that you read the documentation <http://java.sun.com/javase/6/docs/technotes/guides/management/MonitoringGui de.pdf> provided by Sun for monitoring JVMs. You can then start your Jahia, and then start JConsole <http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html> or use LambdaProbe <http://www.lambdaprobe.org/d/index.htm> to view the current status of your server. You can find installation instructions for LambdaProbe here <http://www.lambdaprobe.org/d/installation.shtml> . For JConsole it is simply included in JDK 5 and up, so you just need to start it and connect it to Tomcat once the above configuration in the catalina.bat(.sh) has been done. La question clé est donc de pouvoir déterminer ce qui consomme autant de RAM et pourquoi cela explose au bout d'un certains temps. Bonnes fêtes de fin d'année, Stéphane At 08:25 21.12.2006, you wrote: Hello! Je confirme les mêmes symptômes et tendances de Jahia (et les soucis de mémoire qui en découlent) sur notre configuration qui est la suivante: - Jahia 4.1.1_01 - Red Hat 3 AS - Serveur quadri-xeon - 16 Go RAM - IBM jdk 1.4.2 avec 2,3 Go - MySQL 4.1.20 - 180 sites et 12000 pages publiées Actuellement, notre serveur tient 3 à 4 jours avant de provoquer un OutOfMemory, mais seulement grâce à une mécanique de flush automatique de certains (ou tous) caches de Jahia. Par contre, le saut vers un serveur 64 bits et une jvm 1.5 nous semble également le meilleure moyen à court terme face au problème mémoire. Meilleures salutations. Fabrice Marchon Université de Lausanne Centre informatique > -----Message d'origine----- > De : HENRY Pierre [ <mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED] > Envoyé : mercredi, 20. décembre 2006 17:47 > À : [email protected] > Objet : Problème de mémoire, consommation du cache de Jahia > > Nous avons Jahia 4.1.0, sur une machine Red Hat 3 bi-xeon > avec 2 Go de RAM, avec une machine virtuelle JRockit 1.4.1. > La taille de la Heap est réglée à 1024MB. Nous utilisons la > console JRockit pour surveiller l'état de la VM. Le serveur > est arrêté chaque nuit, le temps de faire un backup de la > base et du système de fichiers de Jahia. > > Pour de nombreuses raison techniques et fonctionnelles, nous > avons divisé notre site web en un nombre important de sites > virtuels (environ 150 actuellement). Le nombre total de pages > sur le serveur est de l'ordre de 10'000. > > Régulièrement et de plus en plus fréquemment (car le nombre > de pages publiées augmente !), nous avons des situations où > le garbage collector de la machine virtuelle n'arrive plus à > libérer suffisament de mémoire. La proportion du CPU utilisée > par ce dernier monte alors jusqu'à 80-80% ( !) et les > performances chutent désastreusement, les temps de réponse > explosent et des erreurs apparaissent sur certaines pages > (mais pas toujours des OutOfMemoryException). Ce problème > devient critique car sa fréquence augmente de plus en plus. > > Il semble que ces plantages soient liés à des visites de > spiders de moteurs de recherche type Google ou autre, qui > contrairement au trafic moyen ne se concentrent pas sur > certaines pages mais explorent l'entièreté des pages du site > (des sites virtuels), forçant le calcul et la mise en cache > de toutes les pages, et remplissant le cache, qui ne semble > pas être doté de purge automatique. Le graphe de > l'utilisation de la heap de Java est à ce sujet très > symptomatique : la mémoire se remplit et se vide au fur et à > mesure des passages du GC, mais la quantité libérée diminue > petit à petit et régulièrement. Au démarrage de Jahia elle se > monte à environ 50% du total de la heap, et diminue jusqu'à > presque rien. > > Ce problème est-il connu, et bien du à la gestion du (des) > cache(s) de Jahia ? Est-il résolu dans une version ultérieure > (Jahia 5) ? Quelles autres solutions sont conseillées ? > > Comme une migration à la version 5n'est de toute façons pas > envisagée dans l'immédiat, j'envisage à court terme de passer > à un serveur 64 bits, ainsi qu'un OS (Red hat 4) et une > machine virtuelle (Jrockit 1.5) 64 bits afin d'éviter la > limitation d'allocation de mémoire des systèmes 32 bits, et > de pouvoir allouer une heap de plusieurs GB. A moyen et long > terme une solution en cluster s'imposera probablement. > > Comment puis-je dimensionner la taille de mémoire suffisante > pour mettre toutes les pages en cache ? Existe-t-il une > estimation de la mémoire consommée en cache par 1 page ? > > Tout conseil est bienvenu ! > > Désolé pour le post un peu indigeste ;) j'ai essayé de > concentrer au maximum les données du problème. > > Cordialement, > > Pierre Henry > Ingénieur de développement > -------------------------------------------------------------- > -------------- > Université de Neuchâtel > Faculté des sciences > SITEL > -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.25/593 - Release Date: 19.12.2006 - -- --- -----=[ scroisier at jahia dot com ]=---- --- -- - Head of Products - Jahia Ltd, Route des Jeunes 9, 1227 Carouge (Switzerland) Jahia : The Java Unified Web Platform www.jahia.org <http://www.jahia.org/> - The Product Web Site www.jahia.net <http://www.jahia.net/> - The Community Web Site www.jahia.com <http://www.jahia.com/> - The Commercial Services Company
