lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless" <luc...@mikemccandless.com>
Subject Re: IndexReader.isCurrent very slow in 2.1
Date Fri, 11 May 2007 17:34:51 GMT

"Andreas Guther" <Andreas.Guther@markettools.com> wrote:
> I moved today from Lucene 2.0 to 2.1 and I noticed that the
> IndexReader.isCurrent() call is very expensive.  What took 20
> milliseconds in 2.0 now takes seconds in 2.1.
> 
> I have the following scenario:
> 
> - 7 index directories of different size, ranging from some MB to 5 GIG 
> - Some index are upgraded to Lucene 2.1, some are still in the old
> format, depending if an update happened or not
> - Cached IndexSearcher for each index
> - I was using the IndexSearcher's indexReader to check if changes
> happened since the Searcher was chached
> 
> The isCurrent check takes between less than 10 millis up to 1400 millis,
> depending on the folder.  The time needed seems not to be relevant to
> the size of the index.

Hmmm, that code did change in 2.1 as part of lockless commits
(LUCENE-701).

Previously we obtained the commit lock, opened the file "segments" and
read the version from that.

Now, we list the directory, locate the segments_N file with the
largest "N" (falling back to "segments" if it exists) and open that
one, and read the version.

Are you always using a 2.1 IndexReader to check isCurrent, and you are
finding that those indexes that have been updated with a 2.1
IndexWriter are the slow ones?

Or, are you comparing 2.0 isCurrent call with the 2.1 isCurrent call?

Are there are large number of files in your index directory?

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message