Hi

-----Original message-----
> From:Shawn Heisey <s...@elyograg.org>
> Sent: Wednesday 28th August 2013 0:50
> To: solr-user@lucene.apache.org
> Subject: Re: SOLR 4.2.1 - High Resident Memory Usage
> 
> On 8/27/2013 4:17 PM, Erick Erickson wrote:
> > Ok, this whole topic usually gives me heartburn. So I'll just point out
> > an interesting blog on this from Mike McCandless:
> > http://blog.mikemccandless.com/2011/04/just-say-no-to-swapping.html
> >
> > At least tuning swappiness to 0 will tell you whether it's real or phantom.
> > Of course I'd be trying it on a test machine, not prod!
> 
> Due to horror stories about operating systems behaving strangely when 
> swap is nonexistent, I don't like to completely disable swap.  I know 
> that if it ever actually starts needing swap that performance will be 
> terrible, but if there is an actual out of memory event and there's no 
> swap at all, then it will start killing off processes, and it might make 
> the wrong choice.

Why? First of all, the OOMKiller in Linux is almost always accurate, it will 
kill your servlet container - although once it also killed my syslogd but that 
was a very experimental set up. If your OS really runs OOM your deamons and/or 
heap allocation is incorrect, or your have too little RAM anyway.

You need to account for additional resident memory plus the heap size your 
allocated, so it's not exact science. But if you know that a 512MB heap never 
results in more than 1024MB RES than you will never run OOM on your OS, and 
therefore never need the swap.

If i can choose i prefer a smaller heap size (living on the edge) and have it 
killed by an OOM script and restart it than rely on the OS' OOMkiller or swap. 
In any case, make sure your servlet container's RES plus the rest of the 
daemons never go beyond your RAM capacity.

Once it swaps, it usually keeps swapping occasionally, or worse :) So keep 
everything in RES, dealing with GC is bad already!


> 
> I do set swappiness to 0 or 1 on all my machines.  I would rather have 
> less commonly used (and very small, memory-wise) processes on special 
> purpose servers (sshd, postfix, etc) remain resident and respond quickly.
> 
> Thanks,
> Shawn
> 
> 

Reply via email to