On 2/17/2015 7:47 AM, Shawn Heisey wrote:
> The first message simply indicates that you have reached more
> simultaneous merges than CMS is configured to allow (3 by default), so
> it will stall all of them except one. The javadocs say that the one
> allowed to run will be the smallest, but I have
On 2/16/2015 8:12 PM, ralph tice wrote:
> Recently I turned on INFO level logging in order to get better insight
> as to what our Solr cluster is doing. Sometimes as frequently as
> almost 3 times a second we get messages like:
> [CMS][qtp896644936-33133]: too many merges; stalling.
time to our epoch.
>
> Recently I turned on INFO level logging in order to get better insight
> as to what our Solr cluster is doing. Sometimes as frequently as
> almost 3 times a second we get messages like:
> [CMS][qtp896644936-33133]: too many merges; stalling...
>
> Less
our epoch.
Recently I turned on INFO level logging in order to get better insight
as to what our Solr cluster is doing. Sometimes as frequently as
almost 3 times a second we get messages like:
[CMS][qtp896644936-33133]: too many merges; stalling...
Less frequently we get:
[TMP][commitScheduler-
On 7/12/2013 9:23 AM, Tom Burton-West wrote:
> Do you have any feeling for what gets traded off if we increase the
> maxMergeCount?
>
> This is completely new for us because we are experimenting with indexing
> pages instead of whole documents. Since our average document is about 370
> pages, thi
nvestigate.
Tom
On Thu, Jul 11, 2013 at 5:29 PM, Shawn Heisey wrote:
> On 7/11/2013 1:47 PM, Tom Burton-West wrote:
>
>> We are seeing the message "too many merges...stalling" in our indexwriter
>> log. Is this something to be concerned about? Does it mean we nee
On 7/11/2013 1:47 PM, Tom Burton-West wrote:
We are seeing the message "too many merges...stalling" in our indexwriter
log. Is this something to be concerned about? Does it mean we need to
tune something in our indexing configuration?
It sounds like you've run into the ma
Hello,
We are seeing the message "too many merges...stalling" in our indexwriter
log. Is this something to be concerned about? Does it mean we need to
tune something in our indexing configuration?
Tom
