[prev in list] [next in list] [prev in thread] [next in thread] 

List:       solr-user
Subject:    Re: maxWarmingSearchers in Solr 4.
From:       Dotan Cohen <dotancohen () gmail ! com>
Date:       2013-04-08 7:23:01
Message-ID: CAKDXFkM3wkDaqpy8SHtJ5YYOKW1tbxLCP5ezBcvLt2f0dde_5Q () mail ! gmail ! com
[Download RAW message or body]

On Thu, Apr 4, 2013 at 10:54 PM, Shawn Heisey <solr@elyograg.org> wrote:
> You'll want to ensure that your autowarmCount value on Solr's caches is low
> enough that each commit happens quickly.  If it takes 5000 milliseconds to
> warm the caches when you commit, then you want to be sure that you are
> committing less often than that, or you'll quickly reach your
> maxWarmingSearchers config value.  If the commits are happening VARY
> quickly, you may need to set autowarmCount to 0, and possibly disable caches
> entirely.
>

I see. This seems to be the opposite of the approach that I was taking.


>>> I went poking in the code, and it seems that maxWarmingSearchers
>>> defaults to Integer.MAX_VALUE.  I'm not sure whether this is a bad
>>> default or not.  It does mean that a pathological setup without
>>> maxWarmingSearchers in the config will probably blow up with an
>>> OutOfMemory exception, but is that better or worse than commits that
>>> don't make new documents searchable?  I can see arguments either way.
>>
>>
>> This is interesting, what you found is that the value in the stock
>> solrconfig.xml file differs from the Solr default value. I think that
>> this is bad practice: a single default should be decided upon and Solr
>> should use this value when nothing is specified in solrconfig.xml, and
>> that _same_value_ should be specified in the stock solrconfig.xml. Is
>> it not a reasonable assumption that this would be the case?
>
>
> That was directed more at the other committers.  I would argue that either a
> low number or a relatively high number should be the default, but not
> MAX_VALUE.  The example config should have a commented out section for
> maxWarmingSearchers that mentions the default.  I'm having the same
> discussion about maxBooleanClauses on SOLR-4586.
>

Right.


> It's possible that this has already been discussed, and that everyone
> prefers that a badly configured setup will eventually have a spectacular
> blow up with OutOfMemory, rather than semi-silently ignoring commits.  A
> searcher object contains caches and uses a lot of memory, so having lots of
> them around will eventually use up the entire heap.
>

Silently dropping data is by far the worse choice, I agree, especially
as a default setting.


--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
[prev in list] [next in list] [prev in thread] [next in thread]