lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Using replicas in SOLR-6.5.1
Date Sun, 28 Jan 2018 20:06:27 GMT
On 1/27/2018 6:53 AM, SOLR4189 wrote:
> 1. You are right, due to memory and garbage collection issues I set each
> shard to different VM. So in my VM I has 50 GB RAM (10 GB for JVM and 40 GB
> for index) and it works good for my using case. Maybe I don't understand
> solr terms, but if you say to set one VM for 20 shards what does it mean? 20
> nodes or 20 JVMs or 20 solr instances on the same virtual server? Can you
> explain what did you mean?

Generally you're going to have one Solr instance per machine, whether 
that machine is physical or virtual.  One Solr instance can handle many 
indexes (cores).  Running multiple Solr instances per machine involves a 
fair amount of overhead, mostly memory, and isn't recommended except for 
some very specific circumstances with *huge* Java heaps.

I can't actually speak for Sameer here, but I think they likely meant 
that you would have two Solr instances, each with 20 cores.  They would 
be in two virtual machines, and ideally, those virtual machines would be 
each hosted by a completely separate physical host.

> 2. I speak about like issues: "facet perfomance regression" or "using ltr
> with grouping" or "using timeAllowed with grouping". Something that will
> stop me to use replicas feature. Sometimes I don't understand solr issues,
> for example, if bug is unresolved and affects version 4.10 and fix version
> none, what does it mean? This bug can happen in solr-6.5.1 also?

It's almost impossible to say whether 6.5.1 would be affected using only 
the version fields in Jira.  Usually if the fix-version is empty, the 
issue hasn't been fixed ... but there are sometimes problems which exist 
in an older version, but have been fixed by a later change.  That later 
change might be completely unrelated to the issue, but the developer 
just happened to see something in the code they examined that they 
didn't like.

What's the issue state?  If it is Closed or Resolved (and the resolution 
says Fixed), then the fix-version SHOULD indicate which versions the fix 
is in or will be in.  If it's not resolved/closed, then it's most likely 
not fixed at all, no matter what the fix-version field states.  As far 
as I am aware, the only state transition that can be automatically done 
by Jira itself is Fixed->Closed, and even that automatic transition only 
takes place with user action -- as part of the release process for a new 
version of Lucene/Solr.  The general rule (which might not always 
happen) is that if the issue is not fixed, fix-version should be empty.


View raw message