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 commi
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 wrote:
> On 9/26/201
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
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 peop
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).
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:
>
>
> false
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 w
