Re: Best combination of workers/CPU cores

From: Pedro Mata-Mouros Fonseca <pedro.matamouros#gmail.com>
Date: Tue, 14 Jul 2009 16:04:01 +0100


Thanks so much Willy. Very valuable info in your email. Cheers.

On Jul 14, 2009, at 12:32 PM, Willy Tarreau wrote:

> Hi,
>
> On Mon, Jul 13, 2009 at 02:47:21PM +0100, Pedro Mata-Mouros Fonseca
> wrote:
>> Greetings,
>>
>> Other than personally testing it very thouroughly, is there any
>> general rule of thumb - regarding HAProxy - as to what combination of
>> worker numbers is the most efficient?
>>
>> I have one HAProxy-only dedicated server with 2 cores and
>> Hyperthreading and 3Gb RAM (actually it's two servers, so it's 4
>> "cores" per server). Should I have one single worker instance per
>> server? Should I have 2? 4? Double of the cores available? Double
>> minus one?
>
> You should *always* have "nbproc 1" (the default). It is too much
> annoying to check stats, logs, control health checks, etc... with
> multiple processes, and it does not bring a noticeable performance
> gain at normal levels. In fact, even with only one process, you can
> make use of multiple cores because the system will be able to run
> the network cards interrupt drivers on other cores and make use of
> them. Even on my 10 Gbps machine, I manage to use 3 cores with only
> one haproxy process, because I have two NICs, each on a different
> core, and haproxy on a third.
>
> The "nbproc" was implemented to workaround very low file-descriptors
> limits under Solaris 2.6, and the only solution to have more than
> 128 concurrent connections was to increase the number of processes.
>
> However, if you can, you should disable hyperthreading on your
> machine, as experience shows that while it helps with CPU intensive
> tasks (eg: compilation, video encoding, ...), it hurts with I/O
> intensive applications (typically network applications). You will
> then get 2 real cores. Having one process the system and the other
> run haproxy provides really good results.
>
> Regards,
> Willy
>
Received on 2009/07/14 17:04

This archive was generated by hypermail 2.2.0 : 2009/07/14 17:15 CEST