Bug #2807
fermé
OutOfMemory sur une réindexation totale
90%
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
- limiter le nombre de threads via un Semaphore
- plus propre : gérér le addFile via une queue JMS
- IndexManager.addFile
- appelle getReader(FileDescription)
- fait appel a Parser.getReader()
- crée un PipedReader
- crée un thread ParserThread
Mis à jour par Stéphanie Fariello il y a plus de 12 ans
- Statut changé de New à Qualified
La qualification de Ludovic devrait suffire.
Mis à jour par Nicolas Eysseric il y a plus de 12 ans
- Statut changé de Qualified à Assigned
- Assigné à mis à Yohann Chastagnier
- Version cible mis à Version 5.11
Mis à jour par Nicolas Eysseric il y a plus de 12 ans
- Statut changé de Assigned à Resolved
- Assigné à changé de Yohann Chastagnier à Emmanuel Hugonnet
- % réalisé changé de 0 à 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...
Mis à jour par Nicolas Eysseric il y a plus de 12 ans
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).
Mis à jour par Nicolas Eysseric il y a environ 12 ans
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
Mis à jour par Nicolas Eysseric il y a environ 12 ans
- Statut changé de Resolved à 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).