Project

General

Profile

Actions

Bug #2807

closed

OutOfMemory sur une réindexation totale

Added by Ludovic Bertin almost 10 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Urgent
Category:
Moteur de recherche
Start date:
01/04/2012
Due date:
% Done:

90%

Estimated time:
Navigateur:
Tous
Votre version de Silverpeas:
5.8
Système d'exploitation:
Votre base de données:
Toutes
Livraison en TEST:
Livraison en PROD:

Description

l'intranet contient de grosses quantité de données et notamment des pièces jointes très lourdes (proches de 100Mo la pièce jointe).
Lors de la réindexation d'une GED avec de tels fichiers, un OutOfMemory survient sur la Heap Space Memory.

Après analyse du code, il apparait que le traitement de l'indexation du fichier déclenche la génération d'un Thread, qui est supprimé des que l'indexation du fichier est terminée.
Mais dans le cas de grosses pièces jointes, le nombre de thread devient trop important et la mémoire allouée grimpe vite, dans le pire des cas 100Mo x nb Threads

Il faudrait donc au choix :
  • limiter le nombre de threads via un Semaphore
  • plus propre : gérér le addFile via une queue JMS
Pour info le cheminement actuel :
  • IndexManager.addFile
  • appelle getReader(FileDescription)
  • fait appel a Parser.getReader()
  • crée un PipedReader
  • crée un thread ParserThread
Actions #1

Updated by Stéphanie Fariello over 9 years ago

  • Status changed from New to Qualified

La qualification de Ludovic devrait suffire.

Actions #2

Updated by Nicolas Eysseric over 9 years ago

  • Status changed from Qualified to Assigned
  • Assignee set to Yohann Chastagnier
  • Target version set to Version 5.11
Actions #3

Updated by Nicolas Eysseric over 9 years ago

  • Status changed from Assigned to Resolved
  • Assignee changed from Yohann Chastagnier to Emmanuel Hugonnet
  • % Done changed from 0 to 90

Lucene a été upgradé dans sa version 3.6.1 et Jackrabbit en 2.5.1.

Les tests sont plutôt concluants.

Test 1
95 Go de données / 4400 fichiers environ
Durée de l'indexation : 40 minutes
Tous les documents bureautiques sont indexés sans erreurs.
Seuls les fichiers PSD génèrent des erreurs.
Les seuls OutOfMemoryError se produisent sur des fichiers de plus de 150Mo (certains de 1.5 Go). Ces erreurs ne bloquent ni l'indexation, ni le serveur...

Test 2
2.5 Go de données / 9000 fichiers environ
Durée de l'indexation : 17 minutes
Pas de OutOfMemoryError

Ces deux tests ont été effectués en utilisant nos parsers (pour les documents bureautiques).

Un autre test est en cours en utilisant exclusivement les parsers de Tika...

Actions #4

Updated by Nicolas Eysseric over 9 years ago

En utilisant exclusivement les parsers fournis par Tika, l'indexation n'est pas plus rapide et il n'y a que très peu d'erreurs (3 fichiers MS Word)...
L'indexation des fichiers OpenOffice ne génère plus d'erreurs (2 erreurs avec notre parser).

Actions #5

Updated by Nicolas Eysseric about 9 years ago

Après avoir upgradé Tika en version 1.2, l'indexation des fichiers volumineux ne génèrent plus de OutOfMemoryError...
Voici les temps d'indexation obtenus avec l'application SilverCrawler :

Test 1
95 Go de données / 4.400 fichiers environ
Durée de l'indexation : 35 minutes
Tous les documents bureautiques sont indexés sans erreurs.
Seuls les fichiers PSD génèrent des erreurs (lié à un bug du PSDParser de Tika)
Taille de l'index : 566 Mo

Test 2
3 Go de données / 10.000 fichiers environ
Durée de l'indexation : 14 minutes
Taille de l'index : 31 Mo

Actions #6

Updated by Nicolas Eysseric about 9 years ago

  • Status changed from Resolved to Closed

Tika a été upgradé vers la version 1.2.
Une anomalie propre à Tika a été corrigé concernant l'indexation des fichiers PSD.

Les corrections effectuées par Emmanuel et transmises à l'équipe de Tika seront intégrées dans la prochaine version (1.3).

Actions

Also available in: Atom PDF