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 time. 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. Thanks, Shawn
