On 25/11/2014 15:46, Emeric Brun wrote:
On 11/24/2014 05:46 PM, Chris Allen wrote:
We have a load balancer running haproxy 1.5.8. At times of heavy load
we're getting dangerously close
to running out of CPU. I'd be really grateful for some definitive
opinions on the relative merits
of the two possible solutions detailed below - as I'm having trouble
finding detailed and consistent
information on them.
1. Nbproc
Our server has 8 cores. We have two primary frontends. We could run
Nbproc=8 assigning
cores 1,2,3,4 to the first frontend and 5,6,7,8 to the other one. But
several documents
say that running Nbproc is not such a great idea (we totally understand
the issue with
stats and don't do admin socket updates or any of the "dangerous
stuff"). If we're ok
with that, is Nbproc a reasonable choice?
Related to nbproc:
- If we do run with nbproc, should we be pinning network interrupts or
just letting irqbalance
handle them? The loadbalancer has 3 bonded NICS generating 15 IRQs - but
no particular NIC
is related to any particular frontend.
- If I bind a frontend to multiple processes, only one of those
processes listens on the TCP
port that I have specified. Yet the other processes seem to receive
requests too. How does
that work? And is the primary process any more loaded for doing the
listening?
2. Distributing interrupts
One of our techops team found an old haproxy.com blog that suggested a
good solution for
balancing cpu load was simply by distributing network interrupts across
available cores
but leaving haproxy to run as a single process. We have tried this and
indeed the *average*
cpu load appears shared across all proceses - but logic tells me that
haproxy must still be
loading each cpu on which it runs and will saturate them (even though
the overall average
looks good). Can anybody comment on this approach as our team member is
convinced
he has a "silver bullet" for performance.
Many thanks for any help/insight into this!
Hi,
Indeed on haproxy.com appliances, we made the choice to dedicate several
cores/CPUs for NICs interrupts (manual bind, no usage of irqbalance) and
to dedicate one other for the haproxy process with nbproc=1.
This configuration offers the most stable performances.
That's also why we recommend for HAPEE users (haproxy entreprise
edition) to choose CPUs with the maximum freq instead numerous cores.
Regards,
Brun Emeric
Hi,
Thanks for your reply. We have tried this approach and while it gives
some benefit, the haproxy process itself
remains cpu-bound, with no idle time at all - with both pidstat and perf
reporting that it uses close to 100%
of available cpu while running.
