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/710?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
