(no subject)

From: Ben Timby <btimby#gmail.com>
Date: Fri, 18 Mar 2011 14:33:32 -0400

On Fri, Mar 18, 2011 at 2:00 PM, Antony <ddjjzz#mail.ru> wrote:
> Hi guys!
> I'm new to HAProxy and currently I'm testing it.
> So I've read this on the main page of the web site:
> "The reliability can significantly decrease when the system is pushed to its limits. This is why finely tuning the sysctls is important. There is no general rule, every system and every application will be specific. However, it is important to ensure that the system will never run out of memory and that it will never swap. A correctly tuned system must be able to run for years at full load without slowing down nor crashing."
> And now have the question.
> How do you usually prevent system to swap? I use Linux but solutions for any other OSes are interesting for me too.
> I think it isn't just to "swapoff -a" and to del appropriate line in /etc/fstab. Because some people say that it isn't good choise..

Prevent swapping by ensuring your resource limits (max connections) etc. keep the application from exceeding the amount of physical memory.

Or conversely by ensuring that your physical memory is sufficient to handle the load you will be seeing.

This is what is referred to in the documentation, you need to tune your limits and available memory for the workload you are seeing. Of course simple things like not running other memory hungry applications on the same machine apply as well. This is an iterative process whereby you observe the application, make adjustments and repeat. You must generate test load within the range of normal operations for this tweaking to be true-to-life. Of course once you go into production the tweaking will continue, no simulation is a replacement for production usage.

The reason running without swap is bad is because if you hit the limit of your physical memory, the OOM killer is invoked. Any process is subject to termination by the OOM killer, so in most cases decreased performance is more acceptable than loss of a critical system process. Received on 2011/03/18 19:33

This archive was generated by hypermail 2.2.0 : 2011/03/18 19:45 CET