lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vsevel <>
Subject Re: Searching while optimizing
Date Fri, 27 Nov 2009 21:12:42 GMT

Hi, I have done some testing that I would like to share with you.

I am starting my tests with an unoptimized 40Mb index. I have 3 test cases:
1) open a writer, optimize, commit, close
2) open a writer, open a reader from the writer, optimize, commit, close
3) same as 2) except the reader is opened while the optimize is done in a
different thread

During all the tests, I monitor the size of the index on the disk. The
results are:
1) initial=41Mb, before end of optimize=122Mb, after end of optimize=81Mb, 
after commit=40Mb,                            after writer close=40Mb
2) initial=41Mb, before end of optimize=122Mb, after end of optimize=104Mb,
after commit=104Mb, after reader close=104Mb, after writer close=40Mb
3) initial=41Mb, before end of optimize=145Mb, after end of optimize=127Mb,
after commit=103Mb, after reader close=103Mb, after writer close=40Mb

>From your different posts I assumed that a commit would have the same effect
as a close as far as reclaiming disk space is concerned. however test cases
2 and 3 show that whether the reader is opened before or during the optimize
we end up after commit with an index that is 2.5 times the nominal size.
closing the reader does not change anything. only a close can get us the
index back to nominal.

What is the reason why the commit nor closing the reader can get us back to
Do you recommend closing and recreating a new writer after an optimize?


Michael McCandless-2 wrote:
> OK, I'll add that to the javadocs; thanks.
> But the fact that you weren't closing the old readers was probably
> also tying up lots of disk space...
> Mike

View this message in context:
Sent from the Lucene - Java Users mailing list archive at

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

View raw message