Thanks, Chris. Adding autoWarming to the filter cache made another big
improvement.
Between increasing the soft commit to 60s, fixing the q:* query, and
autowarming the filter caches my 95% latencies are down to a very acceptable
range — almost an order of magnitude improvement. :-)
-Allan
O
: Slowing the soft commits to every 100 seconds helped. The main culprit
: was a bad query that was coming through every few seconds. Something
: about the empty fq param and the q=* slowed everything else down.
:
: INFO: [event] webapp=/solr path=/select
: params={start=0&q=*&wt=javabin&fq=&f
Slowing the soft commits to every 100 seconds helped. The main culprit was a
bad query that was coming through every few seconds. Something about the empty
fq param and the q=* slowed everything else down.
INFO: [event] webapp=/solr path=/select
params={start=0&q=*&wt=javabin&fq=&fq=startTime:1
On 2/18/2014 11:51 AM, Allan Carroll wrote:
I was thinking GC too, but it doesn’t feel like it is. Running jstat -gcutil
only shows a 10-50ms parnew collection every 10 or 15 seconds and almost no
full CMS collections. Anything other places to look for GC activity I might be
missing?
I did
Thanks for the suggestions.
I was thinking GC too, but it doesn’t feel like it is. Running jstat -gcutil
only shows a 10-50ms parnew collection every 10 or 15 seconds and almost no
full CMS collections. Anything other places to look for GC activity I might be
missing?
I did a little investiga
On 2/17/2014 6:12 PM, Allan Carroll wrote:
> I'm having trouble getting my Solr setup to get consistent performance.
> Average select latency is great, but 95% is dismal (10x average). It's
> probably something slightly misconfigured. I’ve seen it have nice, low
> variance latencies for a few ho
