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 distribution.
Kevin Risden On Thu, Nov 10, 2016 at 6:42 PM, Shawn Heisey <apa...@elyograg.org> 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 > >
