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 >> >> >>