[ 
https://issues.apache.org/jira/browse/LUCENE-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140902#comment-15140902
 ] 

Shai Erera commented on LUCENE-7020:
------------------------------------

bq.  I think users who have very large indexes are more likely to choose larger 
values for TMP

But that's wrong. The number that you set this too is not linearly-related to 
the number of segments in the index. If for instance you have an index a/ 1000 
segments, you wouldn't want to run a merge with {{maxMergeAtOnce=500}} .. not 
sure you'll even have that many resources.

IMO, the only relation between the two settings is that *neither* of them 
should be set so high. I'd even say that if you consider setting 
{{maxMergeAtOnce}} to 30, do the same for {{*Explicit}}. That is, when you set 
a too high value for regular merges, set the same value for explicit merges. 
Unless, you benchmarked your system that found out that merging 100 segments 
together is (a) possible and (b) really improves perf speed of the merge.

> 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

Reply via email to