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 nominal? Do you recommend closing and recreating a new writer after an optimize? thanks vincent 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: http://old.nabble.com/Searching-while-optimizing-tp26485138p26545384.html Sent from the Lucene - Java Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
