lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Queries regarding solr cache
Date Wed, 04 Jan 2017 14:48:25 GMT
On 1/4/2017 3:45 AM, kshitij tyagi wrote:
> Problem:
> I am Noticing that my slaves are not able to use proper caching as:
> 1. I am indexing on my master and committing frequently, what i am noticing
> is that my slaves are committing very frequently and cache is not being
> build properly and so my hit ratio is almost zero for caching.
> 2. What changes I need to make so that the cache builds up properly even
> after commits and cache could be used properly, this is wasting a lot of my
> resources and also slowering up the queries.

Whenever you commit with openSearcher set to true (which is the
default), Solr immediately throws the cache away.  This is by design --
the cache contains internal document IDs from the previous index, due to
merging, the new index might have entirely different ID values for the
same documents.  A commit on the master will cause the slave to copy the
index on its next configured replication interval, and then basically do
a commit of its own to signal that a new searcher is needed.

The caches have a feature called autowarming, which takes the top N
entries in the cache and re-executes the queries that produced the
entries to populate the new cache before the new searcher starts.  If
you set autowarmCount too high, it makes the commits take a really long

If you are committing so frequently that your cache is ineffective, then
you need to commit less frequently.  Whenever you do a commit on the
master, the slave will also do a commit after it copies the new index.


View raw message