Lukas, thank you for pointing to possible keep-alive issues, I've
tested it before, but did it again just to make one more check!
I've increased keep alives timeout to 10se and removed
http-server-close, restarted haproxy :)
Changes I've noted - haproxy reduced from AVG 78% to AVG 75% per each CPU core.
In top I see avg load is 4.10, before restart it was 4.20
Average total bandwidth in frontend interfaces is 250 Mbps and of
course number of ESTABLISHED and all connections is much higer now
(which is OK, there are plenty of RAM there on this server):
[root@router2 ~]# lsof -ni | grep haproxy | grep ESTABLISHED | grep
xxx.xxx.xxx.xxx | wc -l
6568
[root@router2 ~]# lsof -ni | grep haproxy | grep xxx.xxx.xxx.xxx | wc -l
6460
Interesting that interrupts % on CPU0 almost the same at 60%.
Not that much CPU load decrease after changing keep alives, looks it's
something else.
On Sun, Apr 5, 2015 at 2:07 PM, Lukas Tribus <luky...@hotmail.com> wrote:
>> Hi all,
>>
>> haproxy is used for http and https load balancing with TLS termination
>> on haproxy side.
>>
>> I'm using openbsd -stable on this box. I got CPU saturated with
>> 250Mbps traffic in/out summary on frontend NICs and 3000 ESTABLISHED
>> connections on frontent interface to haproxy.
>
>
> Remove:
> option http-server-close
> timeout http-keep-alive 1s
>
>
> and replace them with:
> option http-keep-alive
> option prefer-last-server
> timeout http-keep-alive 10s
>
>
>
> This will enable keep-alive mode with 10 seconds timeout, that should
> decrease the CPU load by an order of magnitude.
>
> The problem with this SSL/TLS terminating setups is the cost involved
> in the SSL/TLS handshake (the actual throughput doesn't really matter).
>
> Also, I suggest to remove the "no-tls-tickets" option, so that your clients
> can use both SSL sessions and TLS tickets to resume a SSL/TLS session
> without starting a full handshake.
>
>
>
> Lukas
>
>
--
--
With regards,
Eugene Sudyr
