Bug #1821
fermé
Réindexation de la plateforme
Ajouté par François Cedelle il y a plus de 13 ans. Mis à jour il y a plus de 13 ans.
100%
Description
Bonjour,
Il nous est impossib de réindexer la plateforme silverpeas, en suivant la procédure indiquée dans la FAQ sur l'extranet.
A chaque essai, on débouche sur un plantage, erreur 500.
Les traces sont en pj.
Nous n'avns actuellement plus d'index...
Fichiers
| traces.tar.gz (3,42 Mo) traces.tar.gz | François Cedelle, 29/03/2011 14:14 |
Mis à jour par François Cedelle il y a plus de 13 ans
- Fichier traces.tar.gz traces.tar.gz ajouté
Mis à jour par Emmanuel Hugonnet il y a plus de 13 ans
- Statut changé de New à Feedback
Les indexes de Jackrabbit sont ils sur un serveur NFS ?
Mis à jour par Emmanuel Hugonnet il y a plus de 13 ans
Il me semblait qu'on avait dit que jackrabbit devait rester sur le filesystem 'standard' car il ne fonctionne pas bien sur NFS < 4
Mis à jour par François Cedelle il y a plus de 13 ans
En effet, mais cette conf spécifique a été perdue avec la mise à jour 5.5...
Bon, peux tu nous rappeler où est la conf du path jackrabbit ?
De plus, j'imagine que je devrais pouvoir l'inclure dans le CustomerSettings avec du xpath ?
Mis à jour par Emmanuel Hugonnet il y a plus de 13 ans
Il s'agit de la propriété jcr.home.dir.url dans le fichier $SILVERPEAS_HOME/properties/com/stratelia/webactiv/util/jcr.properties
Par contre il me semble qie ce fichier n'est pris en compte qu'à la première instanciation de Jackrabbit (à vérifier).
Mis à jour par Nicolas Eysseric il y a plus de 13 ans
- Catégorie mis à Moteur de recherche
- Assigné à mis à Emmanuel Hugonnet
Emmanuel, je ne vois pas le rapport entre l'indexation réalisée avec Lucene et Jackrabbit !
Lors de l'indexation (et de la ré-indexation), Jackrabbit n'est pas utilisé. Alors que les traces montrent le contraire.
Merci de m'éclairer...
Mis à jour par Nicolas Eysseric il y a plus de 13 ans
François, le problème survient lors d'une ré-indexation totale ?
Peux-tu essayer en ne ré-indexant qu'une partie de la plateforme (un seul espace par exemple, voir un seul composant) ?
Le problème pourrait être lié à votre volumétrie.
De plus, des erreurs sont levées lors du parsing de certains types de fichier. Dans ce cas, il semblerait que l'index en cours ne soit pas fermé.
Je vais regarder tout cela de plus près.
Mis à jour par François Cedelle il y a plus de 13 ans
Oui, la réindexation totale plante.
Nous avons tenté la réindexation espace racine par espace racine, ça a planté au bout de quelques espaces...
NB : Sur la préprod, nous avons droit à un permgen space... Il faut que je fasse augmenter la mémoire allouée à Silverpeas.
Mis à jour par Nicolas Eysseric il y a plus de 13 ans
Après analyse des traces, il apparait clairement un java.io.IOException: Too many open files.
Dans le cadre d'une réindexation totale de Silverpeas et avec un nombre important de composant, le nombre maximum de fichiers ouverts peut être rapidement atteint.
Ce nombre doit être augmenté en fonction de la volumétrie de la plateforme.
Voici un article qui décrit la cause du problème ainsi que le mode opératoire pour y pallier :
http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/
Mis à jour par François Cedelle il y a plus de 13 ans
Ok.
Comment estimer la valeur limite à fixer ?
L'indexation ouvre en parallèle un fichier par composant ? Plusieurs ? Quels sont les paramètres utilisés ?
tcao@anthracite:~$ cat /proc/sys/fs/file-max
548481
tcao@anthracite:~$ ulimit -Hn
1024
tcao@anthracite:~$ ulimit -Sn
1024
Mis à jour par Nicolas Eysseric il y a plus de 13 ans
La paramètre ulimit doit être augmenté.
On peut essayer la règle suivante : 2 * nombre de composants.
Mis à jour par François Cedelle il y a plus de 13 ans
Nous avons fixé 32000, et plus de Too many open files à l'horizon..
En revanche, la qualité des résultats laisse à désirer, mais il faut qu'on pousse les tests plus loin. Ce bug peut cependant être fermé.
Mis à jour par Emmanuel Hugonnet il y a plus de 13 ans
- Statut changé de Feedback à Closed