Re: Solr7: Bad query throughput around commit time

Nawab: bq: Cache hit ratios are all in 80+% (even when i decreased the filterCache to 128) This suggests that you use a relatively small handful of fq clauses, which is perfectly fine. Having 450M docs and a cache size of 1024 is _really_ scary! You had a potential for a 57G (yes, gigabyte)

Re: Solr7: Bad query throughput around commit time

~248 gb Nawab On Sat, Nov 11, 2017 at 2:41 PM Kevin Risden wrote: > > One machine runs with a 3TB drive, running 3 solr processes (each with > one core as described above). > > How much total memory on the machine? > > Kevin Risden > > On Sat, Nov 11, 2017 at 1:08 PM,

Re: Solr7: Bad query throughput around commit time

> One machine runs with a 3TB drive, running 3 solr processes (each with one core as described above). How much total memory on the machine? Kevin Risden On Sat, Nov 11, 2017 at 1:08 PM, Nawab Zada Asad Iqbal wrote: > Thanks for a quick and detailed response, Erick! > >

Re: Solr7: Bad query throughput around commit time

Thanks for a quick and detailed response, Erick! Unfortunately i don't have a proof, but our servers with solr 4.5 are running really nicely with the above config. I had assumed that same or similar settings will also perform well with Solr 7, but that assumption didn't hold. As, a lot has

Re: Streaming and large resultsets

Hi Lanny, For long running streaming queries with many shards and huge resultsets, solrj's default settings for http max connections/connections per host may not be enough. If you are using the worker collection (/stream), it depends on dispensing http clients using SolrClientCache with default

Re: Nested facet complete wrong counts

RRGG - [banging my head against the wall] Of course. You are abolutely right about the multi valuedness Thanks for the 7.0 hint. Gives a reason to upgrade. Need to re-index when upgrading? Kenny [image: ONTOFORCE] Kenny Knecht, PhD CTO and technical lead +32 486

Re: Nested facet complete wrong counts

Also, If you're looking at all constraints, you shouldn't need refine:true But if you do need it, it was only added in Solr 7.0 (and I see you're using 6.6) -Yonik On Sat, Nov 11, 2017 at 9:48 AM, Yonik Seeley wrote: > On Sat, Nov 11, 2017 at 9:18 AM, Kenny Knecht

Re: Nested facet complete wrong counts

On Sat, Nov 11, 2017 at 9:18 AM, Kenny Knecht wrote: > Hi Yonik, > > I am aware of the estimate on the hll. But we don't use the hll as a > baseline for comparison. We ask the values for one facet (for example > Gender). We store these counts for each bucket. Next we do

Re: Nested facet complete wrong counts

Hi Yonik, I am aware of the estimate on the hll. But we don't use the hll as a baseline for comparison. We ask the values for one facet (for example Gender). We store these counts for each bucket. Next we do another request. This time for a facet and a subfacet (for example Gender x Type). We sum

Re: Nested facet complete wrong counts

Thank you. But as I showed in my example we used refine and overrequest is not strictly needed because we need all buckets anyway. But that can hardly explain an error of 60%, right? Op 10-nov.-2017 19:29 schreef "Amrit Sarkar" : > Kenny, > > This is a known behavior in