lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Risden <>
Subject Re: Sorl shards: very sensitive to swap space usage !?
Date Thu, 10 Nov 2016 23:44:02 GMT
Agreed with what Shawn and Erick said.

If you don't see anything in the Solr logs and your servers are swapping a
lot, this could mean the Linux OOM killer is killing the Solr process (and
maybe others). There is usually a log of this depending on your Linux

Kevin Risden

On Thu, Nov 10, 2016 at 6:42 PM, Shawn Heisey <> wrote:

> On 11/10/2016 3:20 PM, Chetas Joshi wrote:
> > I have a SolrCloud (Solr 5.5.0) of 50 nodes. The JVM heap memory usage
> > of my solr shards is never more than 50% of the total heap. However,
> > the hosts on which my solr shards are deployed often run into 99% swap
> > space issue. This causes the solr shards go down. Why solr shards are
> > so sensitive to the swap space usage? The JVM heap is more than enough
> > so the shards should never require the swap space. What could be the
> > reason? Where can find the reason why the solr shards go down. I don't
> > see anything on the solr logs.
> If the machine that Solr is installed on is using swap, that means
> you're having serious problems, and your performance will be TERRIBLE.
> This kind of problem cannot be caused by Solr if it is properly
> configured for the machine it's running on.
> Solr is a Java program.  That means its memory usage is limited to the
> Java heap, plus a little bit for Java itself, and absolutely cannot go
> any higher.  If the Java heap is set too large, then the operating
> system might utilize swap to meet Java's memory demands.  The solution
> is to set your Java heap to a value that's significantly smaller than
> the amount of available physical memory.  Setting the heap to a value
> that's close to (or more than) the amount of physical memory, is a
> recipe for very bad performance.
> You need to also limit the memory usage of other software installed on
> the machine, or you might run into a situation where swap is required
> that is not Solr's fault.
> Thanks,
> Shawn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message