Hi Shawn,
Need your help:
I am using master slave architecture in my system and here is the
solrconfig.xml:
<requestHandler name="/replication" class="solr.ReplicationHandler" > <!--
To enable simple master/slave replication, uncomment one of the sections
below, depending on whether this solr instance should be the "master" or a
"slave". If this instance is a "slave" you will also need to fill in the
masterUrl to point to a real machine. --> <lst name="master"> <str name=
"enable">${enable.master:false}</str> <str name="replicateAfter">startup</
str> <str name="replicateAfter">commit</str> <str name=
"commitReserveDuration">00:00:10</str> <str name="confFiles">managed-schema
</str> </lst> <lst name="slave"> <str name="enable">${enable.slave:false}</
str> <str name="masterUrl">http://${MASTER_CORE_URL}/${solr.core.name}</str>
<str name="pollInterval">${POLL_TIME}</str> </lst> </requestHandler>
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.
On Mon, Dec 5, 2016 at 9:06 PM, Shawn Heisey <apa...@elyograg.org> wrote:
> On 12/5/2016 6:44 AM, kshitij tyagi wrote:
> > - lookups:381
> > - hits:24
> > - hitratio:0.06
> > - inserts:363
> > - evictions:0
> > - size:345
> > - warmupTime:2932
> > - cumulative_lookups:294948
> > - cumulative_hits:15840
> > - cumulative_hitratio:0.05
> > - cumulative_inserts:277963
> > - cumulative_evictions:70078
> >
> > How can I increase my hit ratio? I am not able to understand solr
> > caching mechanism clearly. Please help.
>
> This means that out of the nearly 300000 queries executed by that
> handler, only five percent (15000) of them were found in the cache. The
> rest of them were not found in the cache at the moment they were made.
> Since these numbers come from the queryResultCache, this refers to the
> "q" parameter. The filterCache handles things in the fq parameter. The
> documentCache holds actual documents from your index and fills in stored
> data in results so the document doesn't have to be fetched from the index.
>
> Possible reasons: 1) Your users are rarely entering the same query more
> than once. 2) Your client code is adding something unique to every
> query (q parameter) so very few of them are the same. 3) You are
> committing so frequently that the cache never has a chance to get large
> enough to make a difference.
>
> Here are some queryResultCache stats from one of my indexes:
>
> class: org.apache.solr.search.FastLRUCache
> version: 1.0
> description: Concurrent LRU Cache(maxSize=512, initialSize=512,
> minSize=460, acceptableSize=486, cleanupThread=true,
> autowarmCount=8,
> regenerator=org.apache.solr.search.SolrIndexSearcher$3@1d172ac0)
> src: $URL:
> https://svn.apache.org/repos/asf/lucene/dev/
> branches/lucene_solr_4_7/solr/core/src/java/org/
> apache/solr/search/FastLRUCache.java
> lookups: 3496
> hits: 3145
> hitratio: 0.9
> inserts: 335
> evictions: 0
> size: 338
> warmupTime: 2209
> cumulative_lookups: 12394606
> cumulative_hits: 11247114
> cumulative_hitratio: 0.91
> cumulative_inserts: 1110375
> cumulative_evictions: 409887
>
> These numbers indicate that 91 percent of the queries made to this
> handler were served from the cache.
>
> Thanks,
> Shawn
>
>
