first you should reserve resources on your ESX server for your HAProxy box, to ensure it will never wait for the hypervisor to find some resources for it. Then, in the VM, you should tune networking sysctl (tcp port range, tcp rmem, wmem, the syn backlog, etc...)
you can also do CPU affinity per process to ensure no processes will bother HAProxy (usefull under huge load). last chance, move out from the ESX to a physical server :) good luck On Wed, Sep 14, 2011 at 10:04 AM, Christophe Rahier <[email protected]> wrote: > Hi, > > In my case, I searched on my Debian server but I don't find nf_conntrack > ... > > Concerning tuning my whole system, why not but in which direction? :-) > > Regards > > Christophe > > > > Le 14/09/11 00:34, « Willy Tarreau » <[email protected]> a écrit : > >>On Tue, Sep 13, 2011 at 03:31:21PM +0200, Tim Korves wrote: >>> Hi there, >>> >>> >This has nothing to see with haproxy but more how your hypervisor >>> >manages VMs which doesn't do anything :) >>> >>> thanks for the information. Do you have any tips regarding vmWare ESXi >>> 4.1 ? >> >>First, the common suspect : are all of your VMs on the same HV ? Quite >>commonly, what is observed is that involving multiple VMs adds huge >>delays, especially if more total logical CPUs are allocated than the >>total physical ones (which is to be expected because the HV has to >>schedule everyone in turn). >> >>The other common issue when you see something slowing down through >>haproxy is a lack of tuning of the OS, specifically conntrack, but >>this is not related to the VMs at all, it's general. Just in case, >>unload the nf_conntrack module from the machine running haproxy. >>If it changes anything, then either you have to definitely remove >>it because you don't use it, or you need to tune your whole system, >>which is often quite an amusing exercise in VMs ;-) >> >>Regards, >>Willy >> >> >> > > > >
