You are viewing a plain text version of this content. The canonical link for it is here.

Posted to solr-user@lucene.apache.org by Dmitry Kan <so...@gmail.com> on 2013/09/26 14:43:24 UTC

cold searcher

Hello!

Can someone please help me understand the comment in solr 4.3.1's
solrconfig.xml:

    <!-- Use Cold Searcher

         If a search request comes in and there is no current
         registered searcher, then immediately register the still
         warming searcher and use it.  If "false" then all requests
         will block until the first searcher is done warming.
      -->
    <useColdSearcher>false</useColdSearcher>

What precisely happens when userColdSearcher is set to true and a request
arrives while a searcher is warming up?

 - Does the state of warming slow down the search performance? Does it
affect on anything else?

  - How does this setting interplay with soft commits? I.e. do soft-commits
warm up searchers too?

Regards,
Dmitry

Re: cold searcher

Posted by Dmitry Kan <so...@gmail.com>.

Erick,

I actually agree and we are looking into bundling commits into a batch type
update with soft-commits serving the batches and hard commit kicking in
larger periods of time.

In practice, we have already noticed the periodic slow downs in search for
exactly same queries before and after commit points. To describe it
briefly: the queries that used to take lots of time to execute on solr 3.4
now execute super-fast whereas during the periodic slow downs they execute
as slow as on solr 3.4. I bet there is a dependency, as you said, between
the several searchers warmup and caches flushing.

Thanks,

Dmitry

On Fri, Sep 27, 2013 at 3:44 AM, Erick Erickson <er...@gmail.com>wrote:

> Upping the number of concurrent warming searchers is almost always the
> wrong thing to do. I'd lengthen the polling interval or the commit
> interval.
> Throwing away warming searchers is uselessly consuming resources. And
> if you're trying to do any filter queries, your caches will almost never be
> used since you're throwing them away so often.
>
> Best,
> Erick
>
> On Thu, Sep 26, 2013 at 3:52 PM, Shawn Heisey <so...@elyograg.org> wrote:
> > On 9/26/2013 10:56 AM, Dmitry Kan wrote:
> >>
> >> Btw, related to master-slave setup. What makes read-only slave not to
> come
> >> across the same issue? Would it not pull data from the master and warm
> up
> >> searchers? Or does it do updates in a more controlled fashion that makes
> >> it
> >> avoid these issues?
> >
> >
> > Most people have the slave pollInterval configured on an interval that's
> > pretty long, like 15 seconds to several minutes -- much longer than a
> > typical searcher warming time.
> >
> > For a slave, new searchers are only created when there is a change copied
> > over from the master.  There may be several master-side commits that
> happen
> > during the pollInterval, but the slave won't see all of those.
> >
> > Thanks,
> > Shawn
> >
>

Re: cold searcher

Posted by Erick Erickson <er...@gmail.com>.

Upping the number of concurrent warming searchers is almost always the
wrong thing to do. I'd lengthen the polling interval or the commit interval.
Throwing away warming searchers is uselessly consuming resources. And
if you're trying to do any filter queries, your caches will almost never be
used since you're throwing them away so often.

Best,
Erick

On Thu, Sep 26, 2013 at 3:52 PM, Shawn Heisey <so...@elyograg.org> wrote:
> On 9/26/2013 10:56 AM, Dmitry Kan wrote:
>>
>> Btw, related to master-slave setup. What makes read-only slave not to come
>> across the same issue? Would it not pull data from the master and warm up
>> searchers? Or does it do updates in a more controlled fashion that makes
>> it
>> avoid these issues?
>
>
> Most people have the slave pollInterval configured on an interval that's
> pretty long, like 15 seconds to several minutes -- much longer than a
> typical searcher warming time.
>
> For a slave, new searchers are only created when there is a change copied
> over from the master.  There may be several master-side commits that happen
> during the pollInterval, but the slave won't see all of those.
>
> Thanks,
> Shawn
>

Re: cold searcher

Posted by Dmitry Kan <so...@gmail.com>.

Thanks Shawn, the master-slave setup is something that requires separate
study as our update rate is more of bulk type than small incremental bits
(at least at this point). But thanks, this background information always
useful.


On Thu, Sep 26, 2013 at 10:52 PM, Shawn Heisey <so...@elyograg.org> wrote:

> On 9/26/2013 10:56 AM, Dmitry Kan wrote:
>
>> Btw, related to master-slave setup. What makes read-only slave not to come
>> across the same issue? Would it not pull data from the master and warm up
>> searchers? Or does it do updates in a more controlled fashion that makes
>> it
>> avoid these issues?
>>
>
> Most people have the slave pollInterval configured on an interval that's
> pretty long, like 15 seconds to several minutes -- much longer than a
> typical searcher warming time.
>
> For a slave, new searchers are only created when there is a change copied
> over from the master.  There may be several master-side commits that happen
> during the pollInterval, but the slave won't see all of those.
>
> Thanks,
> Shawn
>
>

Re: cold searcher

Posted by Shawn Heisey <so...@elyograg.org>.

On 9/26/2013 10:56 AM, Dmitry Kan wrote:
> Btw, related to master-slave setup. What makes read-only slave not to come
> across the same issue? Would it not pull data from the master and warm up
> searchers? Or does it do updates in a more controlled fashion that makes it
> avoid these issues?

Most people have the slave pollInterval configured on an interval that's 
pretty long, like 15 seconds to several minutes -- much longer than a 
typical searcher warming time.

For a slave, new searchers are only created when there is a change 
copied over from the master.  There may be several master-side commits 
that happen during the pollInterval, but the slave won't see all of those.

Thanks,
Shawn

Re: cold searcher

Posted by Dmitry Kan <so...@gmail.com>.

Thanks for following up the question on IRC!

All right, your explanation makes it more clear, and now the words "until
the *first searcher* is done warming" stand out.

Yes, I have noticed commits in a quick succession (related to the other
question on stamping core names on log entries I asked). They certainly
gave Solr hard time warming up the searchers.
Since we use master-only shards setup (i.e. no slaves), we have increased
the maxWarmingSearchers to 5 and have not yet seen the issue.

Btw, related to master-slave setup. What makes read-only slave not to come
across the same issue? Would it not pull data from the master and warm up
searchers? Or does it do updates in a more controlled fashion that makes it
avoid these issues?

Thanks,
Dmitry

On Thu, Sep 26, 2013 at 5:24 PM, Shawn Heisey <so...@elyograg.org> wrote:

> On 9/26/2013 6:43 AM, Dmitry Kan wrote:
> > Can someone please help me understand the comment in solr 4.3.1's
> > solrconfig.xml:
> >
> >     <!-- Use Cold Searcher
> >
> >          If a search request comes in and there is no current
> >          registered searcher, then immediately register the still
> >          warming searcher and use it.  If "false" then all requests
> >          will block until the first searcher is done warming.
> >       -->
> >     <useColdSearcher>false</useColdSearcher>
>
> As I understand it, this only applies to Solr startup or core reload,
> because that's the only time you'd normally have no registered
> searchers.  The warming queries in that case are defined by
> firstSearcher and newSearcher events, they aren't your cache
> autowarming.  For cache autowarming, you have a registered searcher
> already.
>
> Now I will answer a question that you asked on IRC early this morning
> (in my timezone):  If you are seeing messages in your log about
> exceeding maxWarmingSearchers, then it is likely that the amount of time
> that it takes for warming is exceeding the amount of time before the
> next commit comes in.
>
> Thanks,
> Shawn
>
>

Re: cold searcher

Posted by Shawn Heisey <so...@elyograg.org>.

On 9/26/2013 6:43 AM, Dmitry Kan wrote:
> Can someone please help me understand the comment in solr 4.3.1's
> solrconfig.xml:
> 
>     <!-- Use Cold Searcher
> 
>          If a search request comes in and there is no current
>          registered searcher, then immediately register the still
>          warming searcher and use it.  If "false" then all requests
>          will block until the first searcher is done warming.
>       -->
>     <useColdSearcher>false</useColdSearcher>

As I understand it, this only applies to Solr startup or core reload,
because that's the only time you'd normally have no registered
searchers.  The warming queries in that case are defined by
firstSearcher and newSearcher events, they aren't your cache
autowarming.  For cache autowarming, you have a registered searcher already.

Now I will answer a question that you asked on IRC early this morning
(in my timezone):  If you are seeing messages in your log about
exceeding maxWarmingSearchers, then it is likely that the amount of time
that it takes for warming is exceeding the amount of time before the
next commit comes in.

Thanks,
Shawn