[
https://issues.apache.org/jira/browse/LUCENE-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140762#comment-15140762
]
Shai Erera commented on LUCENE-7020:
------------------------------------
I don't see how {{maxMergeAtOnce}} and {{maxMergeAtOnceExplicit}} are related,
and why there should be any ratio defined between the two. The former specifies
how many segments to merge at once during regular merges, and the latter
specifies the same for {{forceMerge}}. Why should they be dependent on each
other?
I agree with [~mikemccand] that setting any of them too high is risky. If they
user explicitly sets that, that's fine. But if the user sets one of them,
blindly changing the other seems like a surprising effect to me, which could
have negative impact on the performance of the system.
The reason why the 'explicit' setting is higher by default than the
non-explicit one is I believe cause in regular merges, you don't want to
consume too many resources, cause there are other operations (indexing, search)
that happen in parallel. But when you explicitly call {{forceMerge}}, and
assuming you know what you're doing and its impact on the server, you do that
at _quiet_ hours. I wouldn't use the defaults to come up w/ any global
recommended settings for the ratio between these two.
> TieredMergePolicy - cascade maxMergeAtOnce setting to maxMergeAtOnceExplicit
> ----------------------------------------------------------------------------
>
> Key: LUCENE-7020
> URL: https://issues.apache.org/jira/browse/LUCENE-7020
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 5.4.1
> Reporter: Shawn Heisey
> Assignee: Shawn Heisey
> Attachments: LUCENE-7020.patch
>
>
> SOLR-8621 covers improvements in configuring a merge policy in Solr.
> Discussions on that issue brought up the fact that if large values are
> configured for maxMergeAtOnce and segmentsPerTier, but maxMergeAtOnceExplicit
> is not changed, then doing a forceMerge is likely to not work as expected.
> When I first configured maxMergeAtOnce and segmentsPerTier to 35 in Solr, I
> saw an optimize (forceMerge) fully rewrite most of the index *twice* in order
> to achieve a single segment, because there were approximately 80 segments in
> the index before the optimize, and maxMergeAtOnceExplicit defaults to 30. On
> advice given via the solr-user mailing list, I configured
> maxMergeAtOnceExplicit to 105 and have not had that problem since.
> I propose that setting maxMergeAtOnce should also set maxMergeAtOnceExplicit
> to three times the new value -- unless the setMaxMergeAtOnceExplicit method
> has been invoked, indicating that the user wishes to set that value
> themselves.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
