Re: Force open a searcher in solr.
So to make things clear, belows what I am expecting I have a document with a unique id field lets say "uniqueID". This document has both stored/indexed and not stored/ not indexed fields Currently I have my pop values in external files but I will instead define a new field in schema (popVal) which will not be stored or indexed and have docValues=true. I am also moving _version_ field to indexed=false and stored=false, since I don't have any case where I retrieve it and use it for searching. Just hoping doing this doesn't cause any issues with updates in general (I read that keeping this as not stored and not indexed is recommended since solr 7) Regards, Akshay On Thu, Aug 13, 2020 at 4:53 PM Erick Erickson wrote: > Let us know how it works. I want to be sure I’m not confusing you > though. There isn’t a “doc ID field”. The structure of an eff file is > docid:value > > where docid is your . What updating numerics does is allow > you to update a field in a doc that’s identified by . That > field is any name you want as long as it’s defined respecting > the limitations in that link. > > Best, > Erick > > > On Aug 13, 2020, at 6:30 AM, Akshay Murarka wrote: > > > > Hey Erick, > > > > Thanks for the information about the doc ID field. > > So our external file values are single float value fields and we do use > > them in functional queries in boost parameter, so based on the definition > > the above should work. > > So currently we use solr 5.4.0 but are in the process of upgrading our > > systems so will try out this change. > > > > Regards, > > Akshay > > > > On Mon, Aug 10, 2020 at 10:19 PM Erick Erickson > > > wrote: > > > >> Right, but you can use those with function queries. Assuming your eff > >> entry is a doc ID plus single numeric, I was wondering if you can > >> accomplish what you need to with function queries... > >> > >>> On Aug 10, 2020, at 11:30 AM, raj.yadav > wrote: > >>> > >>> Erick Erickson wrote > >>>> Ah, ok. That makes sense. I wonder if your use-case would be better > >>>> served, though, by “in place updates”, see: > >>>> > >> > https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html > >>>> This has been around in since Solr 6.5… > >>> > >>> As per documentation `in place update` is only available for numeric > >>> docValues (along with few more conditions). And here its external field > >>> type. > >>> > >>> Regards, > >>> Raj > >>> > >>> > >>> > >>> -- > >>> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html > >> > >> > >
Re: Reaching max Filter cache limit increases the request latencies.
Hey Erick,
So I am investigating the point where we can limit the values that are
cached using {!cache=false} (we already use it in some of our cases)
So in general there is 0 evictions on filter cache side but whenever we hit
this max limit there is a spike in evictions as well (which is expected)
As far as I remember not forcing enum on our side, but will definitely
verify that.
My filter cache hit ratio remains constant at around 97.5 % and even
during this eviction the hit ratio doesn't go down
Regarding other operation there are a few cases where indexing (80 to 150
docs) also happened during that time but there are also cases where index
happened 5- 10 min after that and the latencies remained high.
Regards,
Akshay
On Thu, Aug 13, 2020 at 5:08 PM Erick Erickson
wrote:
> Well, when you hit the max capacity, cache entries get aged out and are
> eligible for GC, so GC
> activity increases. But for aging out filterCache entries to be
> noticeable, you have to be
> flushing a _lot_ of them out. Which, offhand, makes me wonder if you’re
> using the filterCache
> appropriately.
>
> Here’s what I’d investigate first: What kinds of fq clauses are you using
> and are they making
> best use of the filterCache? Consider an fq clause like
>
> fq=date_field:[* to NOW]
>
> That will consume
> an entry in the filterCache and never be re-used because NOW is the epoch
> time and will change a millisecond later.
>
> Similarly for fq clauses that contain a lot of values that may vary, for
> instance
>
> fq=id:(1 2 4 86 93 …)
>
> where the list of IDs is not likely to be repeated. Or even repeated in a
> different order.
>
> If you do identify patterns that you _know_ will not be repeated, just add
> fq={!cache=false}your_unrepeated_pattern
>
> What I’m guessing here is that if you’ve correctly identified that the
> filterCache filling up
> is increasing GC activity that much, you must be evicting a _lot_ of fq
> entries very rapidly
> which indicates you’re not repeating fq’s very often.
>
> I should add that the filterCache is also used for some other operations,
> particularly some
> kinds of faceting if you specify the enum method. Are you forcing that?
>
> All that said, I’m also wondering if this is coincidence and your slowdown
> is something
> else. Because given all the work a query does, the additional bookkeeping
> due to
> filterCache churn doesn’t really sound like the culprit. Prior to the
> filterCache filling up,
> what’s your hit ratio? The scenario I can see where the filterCache churn
> could cause
> your response times to go up is if, up until that point, you’re getting a
> high hit ratio that
> goes down after the cache starts aging out entries. I find this rather
> unlikely, but possible.
>
> Best,
> Erick
>
> > On Aug 13, 2020, at 3:19 AM, Akshay Murarka wrote:
> >
> > Hey guys,
> >
> > So for quite some time we have been facing an issue where whenever the
> Used Filter Cache value reaches the maximum configured value we start
> seeing an increase in the query latencies on solr side.
> > During this time we also see an increase in our garbage collection and
> CPU as well.
> > When a commit happens with openSearcher=true then only the latencies
> value come back to normal.
> >
> > Is there any setting that can help us with this or will increasing the
> max configured value for filter cache help, because right now we can’t
> increase the commit frequency
> >
> > Thanks for the help.
> >
> > Regards,
> > Akshay
> >
> >
> > Below is the graph for request latency
> >
> >
> >
> >
> >
> >
> > Below is the graph for the Filter cache values
> >
>
>
Re: Force open a searcher in solr.
Hey Erick, Thanks for the information about the doc ID field. So our external file values are single float value fields and we do use them in functional queries in boost parameter, so based on the definition the above should work. So currently we use solr 5.4.0 but are in the process of upgrading our systems so will try out this change. Regards, Akshay On Mon, Aug 10, 2020 at 10:19 PM Erick Erickson wrote: > Right, but you can use those with function queries. Assuming your eff > entry is a doc ID plus single numeric, I was wondering if you can > accomplish what you need to with function queries... > > > On Aug 10, 2020, at 11:30 AM, raj.yadav wrote: > > > > Erick Erickson wrote > >> Ah, ok. That makes sense. I wonder if your use-case would be better > >> served, though, by “in place updates”, see: > >> > https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html > >> This has been around in since Solr 6.5… > > > > As per documentation `in place update` is only available for numeric > > docValues (along with few more conditions). And here its external field > > type. > > > > Regards, > > Raj > > > > > > > > -- > > Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html > >
Re: Force open a searcher in solr.
Hey,
So I have external file fields that have some data that get updated
regularly. Whenever those get updated we need the open searcher operation
to happen. The value in this external files are used in boosting and other
function/range queries.
On Mon, Aug 10, 2020 at 5:08 PM Erick Erickson
wrote:
> In a word, “no”. There is explicit code to _not_ open a new searcher if
> the index hasn’t changed because it’s an expensive operation.
>
> Could you explain _why_ you want to open a new searcher even though the
> index is unchanged? The reason for the check in the first place is that
> nothing has changed about the index so the assumption is that there’s no
> reason to open a new searcher.
>
> You could add at least one bogus doc on each shard, then delete them all
> then issue a commit as a rather crude way to do this. Insuring that you
> changed at least one doc on each shard is “an exercise for the reader”…
>
> Again, though, perhaps if you explained why you think this is necessary we
> could suggest another approach. At first glance, this looks like an XY
> problem though.
>
> Best,
> Erick
>
> > On Aug 10, 2020, at 5:49 AM, Akshay Murarka wrote:
> >
> > Hey,
> >
> > I have a use case where none of the document in my solr index is
> changing but I still want to open a new searcher through the curl api.
> > On executing the below curl command
> > curl
> “XXX.XX.XX.XXX:9744/solr/mycollection/update?openSearcher=true=true”
> > it doesn’t open a new searcher. Below is what I get in logs
> >
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection
> s:shard1_1_1 r:core_node7 x:mycollection_shard1_1_1_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection
> s:shard1_1_1 r:core_node7 x:mycollection_shard1_1_1_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
> org.apache.solr.search.SolrIndexSearcher
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
> org.apache.solr.search.SolrIndexSearcher
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
> org.apache.solr.search.SolrIndexSearcher
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6829) [c:mycollection
&
Force open a searcher in solr.
Hey,
I have a use case where none of the document in my solr index is changing but I
still want to open a new searcher through the curl api.
On executing the below curl command
curl “XXX.XX.XX.XXX:9744/solr/mycollection/update?openSearcher=true=true”
it doesn’t open a new searcher. Below is what I get in logs
2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection s:shard1_1_0
r:core_node6 x:mycollection_shard1_1_0_replica1] o.a.s.u.DirectUpdateHandler2
start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection s:shard1_0_1
r:core_node5 x:mycollection_shard1_0_1_replica1] o.a.s.u.DirectUpdateHandler2
start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection s:shard1_0_0
r:core_node4 x:mycollection_shard1_0_0_replica1] o.a.s.u.DirectUpdateHandler2
start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection s:shard1_1_0
r:core_node6 x:mycollection_shard1_1_0_replica1] o.a.s.u.DirectUpdateHandler2
No uncommitted changes. Skipping IW.commit.
2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection s:shard1_0_1
r:core_node5 x:mycollection_shard1_0_1_replica1] o.a.s.u.DirectUpdateHandler2
No uncommitted changes. Skipping IW.commit.
2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection s:shard1_1_1
r:core_node7 x:mycollection_shard1_1_1_replica1] o.a.s.u.DirectUpdateHandler2
start
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection s:shard1_0_0
r:core_node4 x:mycollection_shard1_0_0_replica1] o.a.s.u.DirectUpdateHandler2
No uncommitted changes. Skipping IW.commit.
2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection s:shard1_1_1
r:core_node7 x:mycollection_shard1_1_1_replica1] o.a.s.u.DirectUpdateHandler2
No uncommitted changes. Skipping IW.commit.
2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection s:shard1_1_0
r:core_node6 x:mycollection_shard1_1_0_replica1] o.a.s.c.SolrCore
SolrIndexSearcher has not changed - not re-opening:
org.apache.solr.search.SolrIndexSearcher
2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection s:shard1_0_1
r:core_node5 x:mycollection_shard1_0_1_replica1] o.a.s.c.SolrCore
SolrIndexSearcher has not changed - not re-opening:
org.apache.solr.search.SolrIndexSearcher
2020-08-10 09:32:22.697 INFO (qtp297786644-6829) [c:mycollection s:shard1_0_0
r:core_node4 x:mycollection_shard1_0_0_replica1] o.a.s.c.SolrCore
SolrIndexSearcher has not changed - not re-opening:
org.apache.solr.search.SolrIndexSearcher
2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection s:shard1_1_0
r:core_node6 x:mycollection_shard1_1_0_replica1] o.a.s.u.DirectUpdateHandler2
end_commit_flush
2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection s:shard1_0_1
r:core_node5 x:mycollection_shard1_0_1_replica1] o.a.s.u.DirectUpdateHandler2
end_commit_flush
2020-08-10 09:32:22.697 INFO (qtp297786644-6829) [c:mycollection s:shard1_0_0
r:core_node4 x:mycollection_shard1_0_0_replica1] o.a.s.u.DirectUpdateHandler2
end_commit_flush
I don’t want to do a complete reload of my collection.
Is there any parameter that can be used to forcefully open a new searcher every
time I do a commit with openSearcher=true
Thanks in advance for the help
Solr reload process flow
Hey, I am using solr-5.4.0 in my production environment and am trying to automate the reload/restart process of the solr collections based on certain specific conditions. I noticed that on solr reload the thread count increases a lot there by resulting in increased latencies. So I read about reload process and came to know that while reloading 1) Solr creates a new core internally and then assigns this core same name as the old core. Is this correct? 2) If above is true then does solr actually create a new index internally on reload? 3) If so then restart sounds much better than reload, or is there any better way to upload new configs on solr? 4) Can you point me to any docs that can give me more details about this? Any help would be appreciated, Thank you. Regards, Akshay
