lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (LUCENE-2898) CMS merge throttling is not aggressive enough
Date Sat, 29 Jan 2011 17:19:43 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael McCandless resolved LUCENE-2898.
----------------------------------------

    Resolution: Fixed

> CMS merge throttling is not aggressive enough
> ---------------------------------------------
>
>                 Key: LUCENE-2898
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2898
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 3.1, 4.0
>
>
> I hit this crab while working on the NRT benchmarker (in luceneutil).
> CMS today forcefully idles any incoming threads, when there are too many merges pending.
> This is the last line of defense that it has, since it also juggles thread priorities
(and forcefully idles the biggest merges) to try to reduce the outstanding merge count.
> But when it cannot keep up it has no choice but to stall those threads responsible for
making new segments.
> However, the logic is in the wrong place now -- the stalling happens after pulling the
next merge from IW.  This is poor because it means if you have N indexing threads, you allow
max + N outstanding merges.
> I have a simple fix, which is to just move the stall logic to before we pull the next
merge from IW.

-- 
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message