[
https://issues.apache.org/jira/browse/LUCENE-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790979#action_12790979
]
Hoss Man commented on LUCENE-2164:
----------------------------------
bq. I also increased the default max thread count from 1 to 2.
random thought from the peanut gallery: do we want to go down the "Ergonomics"
route and make the default number of threads vary based on
Runtime.getRuntime().availableProcessors()
(ie: 1 on a single threaded box, NUM_PROCESSORS/CONSTANT on multithreaded
boxes?)
?
> 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: [email protected]
For additional commands, e-mail: [email protected]
