[
https://issues.apache.org/jira/browse/LUCENE-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791029#action_12791029
]
Michael McCandless commented on LUCENE-2164:
--------------------------------------------
bq. do we want to go down the "Ergonomics" route and make the default number of
threads vary based on Runtime.getRuntime().availableProcessors()
Good idea! How about something like this:
{code}
max(1, min(3, numberOfCores / 2))
{code}
Ie, number of cores divided by 2, but floored at 1 and ceiling'd at 3?
I think 1 BG thread is always good since you gain CPU + IO
concurrency. Too many thread (I'm guess above 3) will swamp the IO
system (unless IO system is SSD).
This would just be a dynamic default, ie, if you call
setMaxThreadCount yourself, you override it.
> Make CMS smarter about thread priorities
> ----------------------------------------
>
> Key: LUCENE-2164
> URL: https://issues.apache.org/jira/browse/LUCENE-2164
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2164.patch
>
>
> Spinoff from LUCENE-2161...
> The hard throttling CMS does (blocking the incoming thread that wants
> to launch a new merge) can be devastating when it strikes during NRT
> reopen.
> It can easily happen if a huge merge is off and running, but then a
> tiny merge is needed to clean up recently created segments due to
> frequent reopens.
> I think a small change to CMS, whereby it assigns a higher thread
> priority to tiny merges than big merges, should allow us to increase
> the max merge thread count again, and greatly reduce the chance that
> NRT's reopen would hit this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
