Re: Multiple fq vs combined fq performance

All non-cached filters will be executed together (leapfrog between them) and will be sorted by the filter cost (I guess that, since you aren't setting a cost, then the order of the input matters). You can try setting a cost in your filters (lower than 100, so that they don't become post filters)

Re: Replica goes into recovery mode in Solr 6.1.0

Sorting and faceting takes a lot of memory. From your charts, I would try a 31 GB heap. That would make GC faster. 680 ms is very long for a GC and can cause problems. Combine a 680 ms GC with a 100 ms soft commit time and you can have lots of trouble. Change your soft commit time to 1 (ten

Re: Multiple fq vs combined fq performance

Thanks for the suggestion, Alex. It doesn't appear that IndexOrDocValuesQuery (at least in Solr 7.7.1) supports the PostFilter interface. I've tried various values for cost on each of the fq and it doesn't change the QTime. So, after digging around a bit even though

Re: Replica goes into recovery mode in Solr 6.1.0

Thanks for quick reply. I assume caches (are they too large?), perhaps uninverted indexes. Docvalues would help with latter ones. Do you use them? >> We do not use any cache. we disabled the cache from solrconfig.xml here is my solrconfig .xml and schema.xml

Re: SOLR / Zookeeper Compatibility

I am new to this SOLR-ZOOKEEPER. I am not able to understand the compatibility thing. For example, I am using SOLR 7.5.0 which uses ZK 3.4.11. So SOLR 7.5.0 will not work with ZK 3.4.10? Can someone please confirm this? Thanks, Mithun Seal -- Sent from:

Re: Replica goes into recovery mode in Solr 6.1.0

vishal patel kirjoitti 10.7.2020 klo 12.45: > Thanks for your input. > > Walter already said that setting soft commit max time to 100 ms is a recipe > for disaster >>> I know that but our application is already developed and run on live >>> environment since last 5 years. Actually, we want to

Re: Replica goes into recovery mode in Solr 6.1.0

Thanks for your input. Walter already said that setting soft commit max time to 100 ms is a recipe for disaster >> I know that but our application is already developed and run on live >> environment since last 5 years. Actually, we want to show a data very >> quickly after the insert. you

Re: I Became a Solr Committer in 4662 Days. Here’s how you can do it faster!

thanks for share. nice article. Charlie Hull wrote: Thought you might enjoy Eric's blog, it's taken him a while! Some good hints here for those of you interested in contributing more to Solr.

Re: I Became a Solr Committer in 4662 Days. Here’s how you can do it faster!

Thanks, interesting reading On Fri, Jul 10, 2020 at 11:18 AM Charlie Hull wrote: > Hi all, > > Thought you might enjoy Eric's blog, it's taken him a while! Some good > hints here for those of you interested in contributing more to Solr. > > >

PayloadCheckQParserPlugin Increase the operator parameter

Hi: Hope PayloadCheckQParserPlugin can support operator parameters, support the operator is a phrase or or multiple values. As PayloadScoreQParserPlugin 1. Analyze parameters. localParams.get("operator", DEFAULT_OPERATOR); 2. Create SpanQuery, call

I Became a Solr Committer in 4662 Days. Here’s how you can do it faster!

Hi all, Thought you might enjoy Eric's blog, it's taken him a while! Some good hints here for those of you interested in contributing more to Solr. https://opensourceconnections.com/blog/2020/07/10/i-became-a-solr-committer-in-4662-days-heres-how-you-can-do-it-faster/ Cheers Charlie --

Re: Replica goes into recovery mode in Solr 6.1.0

Walter already said that setting soft commit max time to 100 ms is a recipe for disaster. That alone can be the issue, but if you're not willing to try higher values, there's no way of being sure. And you have huge JVM heaps without an explanation for the reason. If those do not cause problems,