With LogXMergePolicy (the default before 3.2), optimize respects mergeFactor, so it's doing 2 steps because you have 37 segments but 35 mergeFactor.
With TieredMergePolicy (default on 3.2 and after), there is now a separate merge factor used for optimize (maxMergeAtOnceExplicit)... so you could eg set this factor higher and more often get a single merge for the optimize. Mike McCandless http://blog.mikemccandless.com On Sat, Jun 18, 2011 at 6:45 PM, Shawn Heisey <s...@elyograg.org> wrote: > I've noticed something odd in Solr 3.2 when it does an optimize. One of my > shards (freshly built via DIH full-import) had 37 segments, totalling > 17.38GB of disk space. 13 of those segments were results of merges during > initial import, the other 24 were untouched after creation. Starting at _0, > the final segment before optimizing is _co. The mergefactor on the index is > 35, chosen because it makes merged segments line up nicely on "z" > boundaries. > > The optmization process created a _cp segment of 14.4GB, followed by a _cq > segment at the final 17.27GB size, so at the peak, it took 49GB of disk > space to hold the index. > > Is there any way to make it do the optimize in one pass? Is there a > compelling reason why it does it this way? > > Thanks, > Shawn > >
