lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2898) CMS merge throttling is not aggressive enough
Date Sun, 30 Jan 2011 14:28:45 GMT

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

Shai Erera commented on LUCENE-2898:
------------------------------------

So if the user allows for N max-merges in CMS, and MP returns N merges to be executed, then
this is fine. If however MP returns N + 1 merges, then CMS will register N + 1 merges, and
then stall? I'm asking because the while() checks for mergeThreadCount() >= 1 + maxMergeCount.

Before your changes, at most maxMergeCount merges could be registered, while now the code
allows for maxMergeCount + 1? I'm confused.

And my question I think is stil valid - what if CMS waits for nothing - meaning after wait()
finishes, IW.getNextMerge() returns null? The user thread will be blocked until then, even
though no more merges are 'pending'?

Perhaps I'm just confused though ... :)

> 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