lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Lucene reorganizing indexes
Date Mon, 16 Jul 2012 20:47:26 GMT
You may want to read:

Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen

> -----Original Message-----
> From: Scott Smith []
> Sent: Monday, July 16, 2012 10:29 PM
> To:
> Subject: Lucene reorganizing indexes
> We have an application that has to do "real time" indexing of a number of
> documents.  What it does is wake up about every 20 seconds and updates the
> index with any changes that have been queued since the last time it ran.
> involves adding and deleting several hundred documents.  This is all done
in a
> single thread.  There can be multiple threads doing searches simultaneous
> the update thread (the searches run in a different process).
> Back in the days of 1.42, we would force an index optimization once each
> However, my impression is that the later versions of Lucene (we are
> using 3.5), Lucene will often do its own reorganization based on hitting
> criteria.  I've been told that optimizing the index is, perhaps, no longer
> necessary.  Can someone describe what happens here?
> The reason I'm asking about this is that we see our application
> using excessive amounts of kernel time (on Windows) which normally
> a lot of disk activity.  We are unable to align this with anything our
code is
> doing.  Obviously, we expect Lucene to be causing disk activity, it just
> that the last release (we were at 3.02 before going to 3.5) severely
> the disk activity which is interfering with other things running on the
> Does any of this make sense to anyone?  Is there an explanation?  Thoughts
> about what we might do about it?
> Thanks in advance.
> Scott

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message