Re: RE : RE : [sdx-users] V ers l'infini et au delà !

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit:

> Si je ne me trompe pas, il y a un seul searcher d'ouvert par base de
> documents. Donc un pool de taille 1.

Oui... sauf bug.

> Ce que tu voudrais, c'est qu'il y ait, par exemple, 10 searcher dans un
> seul pool pour l'ensemble du serveur, et pour chaque demande de searcher
> dans le pool on devra aller ouvrir le searcher sur le bon index?

C'est ça. Et, surtout, quand un searcher (ou un reader/writer quelconque 
à vrai dire) est recyclé, qu'on le ferme *explicitement*.

D'après le message dont j'ai donné la référence, il semble que le design 
de Lucene fasse trop confiance au ramasse-miettes et que les ressources 
ne soient libérées que... trop tard :-) Une réponse au dit message 
semble d'ailleurs le confirmer :

> it's not bug but feature. lucene don't close files after searching only if you call 
> the close() method. the cause: it's very slow to reopen the files.

Mon analyse est que, quand l'index est constitué, on doit être assez 
optimal dans l'utilisation des ressources. En revanche, quand on modifie 
l'index est fortement variable (uploads), on arrive en plein dans cette 
problématique qui semble prendre des proportions incroyables chez 
certains d'entre nous. Je dois avouer que je n'ai pas encore bien 
compris de quelle façon la réutilisation d'un searcher amenait à 
demander de nouvelles ressources alors qu'il est censé disposer de tout 
ce qui lui faut.

V. aussi à ce propos :
http://rhea.redhat.com/doc/release-notes/WAF_RELEASE_NOTES_52.html, 
Change 27880

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden