Bonjour, Voici une des mesures que nous avons prises concernant l'indexation des sites web par les moteurs de recherche, aussi bien en interne qu'en externe: diminuer le timeout de session pour les utilisateurs non-identifiés (guest) de 30 minutes à 10 minutes; par contre, les utilisateurs ou rédacteurs de sites continuent à avoir une session de 30 minutes. Cette mesure a permis de diminuer de moitié en tout cas le nombre de sessions existantes sut notre tomcat 5 (de 1500 à 700).
Concernant le mécanisme de flush des caches de Jahia, il est vrai que certains caches ne doivent pas être flushés en runtime comme les acls ou les fichiers webdav, mais les autres le sont sans problème à ma connaissance ; en effet, cela fait environ 6 mois que cela tourne chez nous. Cependant, comme nous avions déjà des problèmes de OutOfMemory, cela nous a permis d'en ralentir l'apparation et la fréquence. Notre mécanisme de flush de caches est composé de 2 éléments: un script (programme Java) et un template d'administration. Le template d'administration se trouve sur une page protégée et inclut des formulaires et les méthodes pour lancer le flush d'un, plusieurs ou tous les caches via l'API Jahia. Le script quant à lui se connecte à la page protégée basée sur le template d'administration et active un formulaire, par exemple de flush de tous les caches ; le script est actionné périodiquement via la crontab de l'OS. Sur vous souhaitez plus d'info, je suis à votre disposition. A+ ----------------------------------------- Fabrice Marchon Université de Lausanne Centre informatique > -----Message d'origine----- > De : Serge Huber [mailto:[EMAIL PROTECTED] > Envoyé : mardi, 9. janvier 2007 14:14 > À : [email protected] > Objet : Re: Problème de mémoire, consommation du cache de Jahia > > > Bonjour, > > Il est quasiment impossible de "deviner" ce qui peut causer > un OutOfMemory. Mais dans la version 4 de Jahia il est TRES > important de limiter la taille des caches en les configurant > dans le jahia.properties, sinon Jahia va utiliser toute la > mémoire disponible. > > Une récente expérience sur un projet nous a aussi permi de > voir que dans certaines charges les sessions pouvaient aussi > consommer de la mémoire qui n'est pas libérée suffisemment vite. > > Nous recommendons d'installer différent outils de monitoring > afin de pouvoir tracer l'utilisation mémoire, afin de pouvoir > surveilller et/ou diagnostiquer les problèmes mémoires. Je > vous oriente donc vers mon article dans mon blog ici : > https://www.jahia.net/jahia/Jahia/op/edit/cache/offonce/pid/71 > 0?entryId=3301 > . Certains de ces outils sont spécifiques à la version 5 SP 1 > de Jahia (comme par exemple l'utilisation de la JDK 6), mais > d'autres peuvent être utilisés avec Jahia 4 (comme YourKit, > LambdaProbe ou MessAdmin). > > Evidemment la limitation des JVM 32bit à 2GB est un autre > problème, et c'est pourquoi pour de grosses installations > nous recommandons aussi des machines virtuelles 64bit. > > Salutations, > Serge Huber. > > HENRY Pierre wrote: > > Bonjour, > > > > Merci pour vos réponses, désolé pour le retard (période de > fêtes oblige). > > > > Je suis rassuré de voir que nous ne sommes pas les seuls à > avoir ce genre de problèmes. > > > > Après installation sur un nouveau serveur 64 bits avec 4 GB > de RAM, et quelques essais avec Jmeter, je confirme que cette > config sera la solution à court terme que nous allons adopter > (Red hat 4 + Jrockit 1.5 + 3 GB pour la heap (Xmx)). > > > > Pour ce qui est de limiter l'accès aux robots, ce n'est pas > vraiment envisageable, ne serait-ce que parce que nous > utilisons google search comme méthode de recherche standard > sur notre site (ce qui englobe également quelques serveurs > non jahia). De plus les utilisateurs nous demandent déjà > d'améliorer le référencement dans les moteurs de recherche ! > > > > En ce qui concerne ce mécanisme de flush automatique des > caches, serait-il possible d'en dire plus ? Mon prédécesseur > qui a mis en place Jahia ici m'avait déconseillé de toucher > aux purges de caches de Jahia, je n'ai donc pas trop cherché > de ce côté. > > > > Meilleures salutations, > > > > Pierre Henry > > Ingénieur de développement > > > ---------------------------------------------------------------------- > > ------ > > Université de Neuchâtel > > Faculté des sciences > > SITEL > > > > > > -----Message d'origine----- > > De : Fabrice Marchon [mailto:[EMAIL PROTECTED] > Envoyé : jeudi, > > 21. décembre 2006 08:26 À : [email protected] Objet : > RE: Problème > > de mémoire, consommation du cache de Jahia > > > > 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] 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
