Correct, do not optimize.

“Optimize” was a bad choice for this action. It is a forced merge.

With master/slave, it means the slaves must always copy the entire
400 GB index. Without optimize, they would only need to copy the 
changed segments.

Solr automatically merges segments for you.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jun 4, 2019, at 2:34 AM, Midas A <test.mi...@gmail.com> wrote:
> 
> So we should not optimize our index ?
> 
> On Tue, Jun 4, 2019 at 2:37 PM Toke Eskildsen <t...@kb.dk> wrote:
> 
>> On Tue, 2019-06-04 at 11:48 +0530, Midas A wrote:
>>> Index size is 400GB. we used master slave architecture .
>>> 
>>> commit is taking time while not able to perform optimize .
>> 
>> Why do you want to optimize in the first place? What are you hoping to
>> achieve?
>> 
>> There should be an error message in your Solr log from the failed
>> optimize, so see if you can find that. At least for some Solr versions,
>> optimize can be quite memory hungry so a very quick guess is that you
>> have hit an OutOfMemory. Not enough disk space is also a guess: Make
>> sure you have 2*index size free space before optimizing as worst case
>> for storage usage during optimize is a total of 3*index size.
>> 
>> - Toke Eskildsen, Royal Danish Library
>> 
>> 
>> 

Reply via email to