lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kshitij tyagi <kshitij.shopcl...@gmail.com>
Subject Re: Queries regarding solr cache
Date Wed, 04 Jan 2017 10:45:14 GMT
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 <apache@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message