Support #3459
fermé
Réindexation v5.9.2
Ajouté par Emmanuel GRANGE il y a presque 12 ans. Mis à jour il y a plus de 11 ans.
100%
Description
Bonjour,
J'ai lancé hier une réindexation de tout le portail.
Il a tourné de 13:30 jusqu'à 18:41, mais n'a pas effectué toute la réindexation demandé (1/3 uniquement).
De plus, de nombreuses erreurs d'indexation ont été détectées lors de l'indexation, soit sur des erreurs de lecture du fichier, soit sur l'écriture des index, et d'autres encore...
Il semble aussi qu'il y ait des erreurs de manque de mémoire.
Ci-joint le fichier de trace de toutes l'indexation
Fichiers
| traces-indexation.zip (46,2 ko) traces-indexation.zip | Traces indexation | Emmanuel GRANGE, 27/06/2012 10:29 | |
| traces.20120627.zip (93,1 ko) traces.20120627.zip | Emmanuel GRANGE, 28/06/2012 13:24 | ||
| traces.indexation.20120629-0702.zip (61,3 ko) traces.indexation.20120629-0702.zip | Emmanuel GRANGE, 02/07/2012 14:55 |
Mis à jour par David Lesimple il y a presque 12 ans
- Statut changé de New à Feedback
A partir du moment où il y a un java.lang.OutOfMemoryError (26/06/12-18:05:03,376), le fonctionnement du portail (et donc de l'indexation) est compromis.
Quelle est la mémoire du serveur et celle allouée au portail ?
Si celle-ci est trop faible, il est conseillé de fractionner la réindexation (espaces de 1er niveau à lancer unitairement) pour éviter ces problèmes.
Mis à jour par Emmanuel GRANGE il y a presque 12 ans
Le serveur a 4Go de mémoire et voici les infos de mon config.xml :
- JBOSS_SERVER_PROFILE=default
RAM_MIN=1024
RAM_MAX=2048
PERMSIZE_MAX=512 - JAVA_OPTS=
Dans la version précédente, nous devions ajouter les lignes suivantes dans le silverpeas_start_jboss.sh :
ulimit -Hn 16384
ulimit -Sn 8192
Est-ce toujours d'actualité ?
Mis à jour par David Lesimple il y a presque 12 ans
oui si il y a des Too Many Open files dans server.log de Jboss.
Mis à jour par David Lesimple il y a presque 12 ans
D'autre part, il ne faut plus faire référence au config.xml qui n'est plus utilisé, mais au config.properties
il faudra augmenter la valeur de RAM_MAX
Mis à jour par Emmanuel Hugonnet il y a presque 12 ans
- Statut changé de Feedback à New
L'indexation complète lance un certain nombre de threads : chacun a sa propre pile d'exécution et donc ca peut devenir très consommateur en ressources mémoire.
L'indexation par espaces permet d'avoir moins de threads en parallèle et donc moins de consommation mémoire.
Mis à jour par Emmanuel GRANGE il y a presque 12 ans
- Fichier traces.20120627.zip traces.20120627.zip ajouté
J'ai augmenté temporairement la mémoire du serveur, et j'ai alloué 8Go à jboss, le temps de finir l'indexation.
Il y a cependant énormément d'erreurs d'ouverture de fichier, ou d'écriture d'index pour tous types de fichiers (xls, pdf, doc...)
Mis à jour par Emmanuel GRANGE il y a presque 12 ans
Une fois l'indexation complète terminée, est-il possible de réutiliser le résultat (SILVERPEAS_DATA_HOME/index) sur notre portail de production et de ne relancer qu'une "incrémentale" ?
Mis à jour par David Lesimple il y a presque 12 ans
- Statut changé de New à Feedback
Vous avez redémarré Silverpeas et l'indexation après avoir augmenté la mémoire ?
Sinon peut-on avoir quelques fichiers qui ne passent pas (un .tiff, un .docx, un .xls) à prendre dans le log ?
Mis à jour par Emmanuel Hugonnet il y a presque 12 ans
Pour les tiff c'est un problème de version de librairie qui a été corrigé pour la 5.10 (bug #3404)
Pour les xls cela aussi a été corrigé en 5.10 (le parsing coupait le flux dès que les informations étaient récupérées ce qui induisait cette erreur).
Pour les docx par contre je suis preneur car normalement cela se passe bien (il y a même un test unitaire exécuté à chaque buid). S'agit il d'un document produit avec Office 2007 ou 2010 ? Pourriez vous nous fournir un exemple ?
Mis à jour par Emmanuel GRANGE il y a presque 12 ans
Je ne saurais dire de quelle version d'office il s'agit, mais les fichiers ne s'ouvrait déjà pas normalement sous office 2007.
J'ai mis des exemples sur l'extranet : https://extranet.silverpeas.com/silverpeas/Publication/7101
Serait-il possible d'avoir un patch sur la version v5.9.2, car nous avons prévu de migrer la semaine prochaine.
Mis à jour par Emmanuel Hugonnet il y a presque 12 ans
Il ne me semble pas possible de produire un tel patch car cela a été intégré dans un refactoring de code et donc n'est pas applicable sur une version 5.9 sans de gros risques de stabilité.
Pour les fichiers tiff cela demande une montée de version de certaines librairies ce qui peut être éventuellement fait à la main en attendant la 5.10.
Concernant vos fichiers docx, je n'arrive pas à les ouvrir avec LibreOffice et Office 2007 les déclare corrompus (avant de proposer d'essayer de les réparer). Le problème vient donc bien de vos fichiers.
Mis à jour par Emmanuel GRANGE il y a presque 12 ans
J'ai lancé une nouvelle indexation pendant le week-end avec 8Go dédié à jboss
La synchronisation a tourné pendant les 2 jours complet (lancé vendredi à 17:30) et elle n'a toujours pas fini (~1/3).
Elle a bien sûr utilisé toute la mémoire disponible.
J'ai du forcer l'arrêt manuellement, et le serveur est devenu très lent. je l'ai donc rebooté.
D'ailleurs avec 8Go de mémoire dédié à Jboss, le portail met 17 minutes à démarré.
Si je consulte la commande de lancement du portail : Xms=Xmx. Est-ce normale ?
Mis à jour par David Lesimple il y a presque 12 ans
il n'y a pas d'erreur système dans les logs (du style outofmemory) ?
Quelle est le volume de données à indexer ?
Oui il est conseillé de mettre la valeur maximale de RAM en Xms et Xmx.
Sinon, je trouve que 17' c'est énorme... Essaye de gonfler les ressources CPU pour voir si cela démarre plus vite.
Mis à jour par Emmanuel GRANGE il y a presque 12 ans
Cette fois-ci, il n'y a pas ce genre d'erreurs.
Principalement des erreurs de parsing (cf traces ci-joint).
Nous avons actuellement 60Go de données.
Pour mes essais, j'ai réduit la mémoire allouée pour que les démarrages soient plus rapide.
Mais même avec 2Go alloué, il met 14' à démarrer.
Mis à jour par Emmanuel Hugonnet il y a presque 12 ans
Bonjour,
Désactiver le rechargement des properties permet de gagner aussi sur la mémoire utilisée par Silverpeas.
Etes vous sur une machine 64 bits ?
Le nombre de composants et d'utilisateurs a un coût direct sur le démarrage de Silverpeas car une bonne partie est mise en cache au démarrage justement (et un mode lazy n'est hélas pas possible sur cette partie).
Mis à jour par Emmanuel GRANGE il y a presque 12 ans
S'il n'est pas activé par défaut, je ne l'ai pas activé alors.
Je suis sur debian6 64 bits
Chose étrange, je n'avais pas ce problème avant que je ne lance l'indexation de ce week-end !!
Mis à jour par Emmanuel GRANGE il y a presque 12 ans
A priori, le temps de chargement long est dû à mes tests sur la navigation mixte que je n'arrive pas à faire fonctionner (https://www.silverpeas.org/redmine/issues/3484).
La réindexation pose toujours des problèmes. Je vais faire des indexations espace par espace.
Mais la mémoire se libère-t’elle une fois l'indexation terminée ? (pour l'instant toutes les indexations que j'ai lancé ne se sont jamais fini !)
Qu'en est-il de ma question sur le déplacement des résultats de l'indexation ci-dessus :
Est-il possible de réutiliser le résultat (SILVERPEAS_DATA_HOME/index) sur notre portail de production et de ne relancer qu'une "incrémentale" ?
Mis à jour par David Lesimple il y a plus de 11 ans
- Statut changé de Feedback à Closed
- % réalisé changé de 0 à 100
Suite à nos nombreux échanges, je pense que ce problème est réglé.