[
https://issues.apache.org/jira/browse/SOLR-11581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227120#comment-16227120
]
Amrit Sarkar commented on SOLR-11581:
-------------------------------------
Nawab,
We, at my workplace, tried to get some relevant numbers testing various
scenarios to summarise what works and what not with optimising resources at
bulk indexing. We will share the article in public very soon.
Meanwhile, please try out this particular combination:
1. "*NoMergePolicy*" instead of default TieredMergePolicy; I don't think you
need NoMergeSchedular for achieving no merges. ConcurrentMergeSchedular will
execute barely some portion of code before bouncing back.
2. "*useCompoundFile*" in <indexConfig> so that optimised segments are written
over.
3. Increase *ramBufferSize* (default 100MB) to a higher number, how much, that
is machine specific, so that segments gets only written when the threshold
"ramBufferSize" tips over.
See more about this official guide:
https://lucene.apache.org/solr/guide/6_6/indexconfig-in-solrconfig.html
> NoMergeScheduler ctor should be public for allowing instantiation from SOLR
> ---------------------------------------------------------------------------
>
> Key: SOLR-11581
> URL: https://issues.apache.org/jira/browse/SOLR-11581
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Nawab Zada Asad iqbal
> Priority: Minor
>
> There are scenarios where a SOLR user may want to use NoMergeScheduler.
> However, it is not possible to use it today, since its constructor is private
> and solrconfig.xml requires a Scheduler with public constructor.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
