2.0.1 cpu Usage at near 100% after upgrade from 1.5

@joel-l please file a bug on github:

Thanks, created: https://github.com/haproxy/haproxy/issues/411

1 Like

Hello,

I am finally able to get back to testing the latest release. I am still experiencing significant CPU usage on the new 2.0.17 release compared to 1.6.14.

On 2.0.17, CPU usage for the two threads is around 75% each:

150433 haproxy 20 0 1709760 968884 247944 R 75.8 1.5 7:17.47 haproxy
150434 haproxy 20 0 1709760 968884 247944 S 75.8 1.5 7:12.24 haproxy

On 1.6.14, CPU usage for the two procs is under 35% each:

154476 haproxy 20 0 519152 15292 2744 R 34.8 0.0 0:22.73 haproxy
154496 haproxy 20 0 517880 50340 37792 S 32.8 0.1 0:21.51 haproxy

There is something extremely inefficient with the newer branch.

I attempted to use the simplified config for 2.0 that only uses 2 processes, no threading, no health checks. Still extremely high CPU usage compared to 1.6 which has health checks and what not.

~75% CPU usage on 2.0.17.

159708 haproxy 20 0 173140 90180 3196 S 75.4 0.1 0:58.53 haproxy-2.0
159709 haproxy 20 0 174020 90236 3184 S 74.4 0.1 0:57.72 haproxy-2.0

The results of the ss command are below:
1995 ESTAB
10 LISTEN

Could you test 2.2.2 ? I believe there are substantial improvements in 2.2.

There does not appear to be a repository for haproxy 2.2 for Ubuntu 16. I am not sure when I will have time to setup a build environment.

Hello lukastribus,

I was able to take some personal time to compile 2.2.2. Unfortunately I did not see any improvements. It still used about the same amount of CPU as 2.0.17.

I did not compile in LUA or PCRE since they both wanted some more development tools involved and I do not use them in this basic config. I would hope that this would not cause a problem.

/usr/sbin/haproxy-2.2 -vv

HA-Proxy version 2.2.2 2020/07/31 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2025.
Known bugs: http://www.haproxy.org/bugs/bugs-2.2.2.html
Running on: Linux 4.4.0-141-generic #167-Ubuntu SMP Wed Dec 5 10:40:15 UTC 2018 x86_64
Build options :
TARGET = linux-glibc
CPU = generic
CC = gcc
CFLAGS = -O2 -g -Wall -Wextra -Wdeclaration-after-statement -fwrapv -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers -Wtype-limits
OPTIONS = USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1

Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H +GETADDRINFO +OPENSSL -LUA +FUTEX +ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS

Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=40).
Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with network namespace support.
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity(“identity”), deflate(“deflate”), raw-deflate(“deflate”), gzip(“gzip”)
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built without PCRE or PCRE2 support (using libc’s regex instead)
Encrypted password support via crypt(3): yes
Built with gcc compiler version 5.4.0 20160609

Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as cannot be specified using ‘proto’ keyword)
fcgi : mode=HTTP side=BE mux=FCGI
: mode=HTTP side=FE|BE mux=H1
h2 : mode=HTTP side=FE|BE mux=H2
: mode=TCP side=FE|BE mux=PASS

Available services : none

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
[CACHE] cache
[FCGI] fcgi-app

Also, I tried a second build of 2.2.2 with DEFINE="-DMAX_READ_POLL_LOOPS=1" and this did not help either.

It’s difficult for me to do a controlled test, but I ran a few more. There appear to be some gains in 2.2, but not enough to offset the losses that exist in 2.0 compared to 1.6.

195572 haproxy   20   0  524540  21072   1988 R  28.5  0.0   0:08.49 haproxy-1.6
195592 haproxy   20   0  525296  37236  17436 S  28.1  0.1   0:08.34 haproxy-1.6

195277 haproxy   20   0  163592  81580   3016 S  56.2  0.1   0:07.23 haproxy-2.0
195276 haproxy   20   0  163920  81848   3056 S  50.0  0.1   0:08.04 haproxy-2.0

195039 haproxy   20   0  159852  75164   3476 R  45.0  0.1   0:18.01 haproxy-2.2
195040 haproxy   20   0  160020  75620   3480 S  45.0  0.1   0:18.71 haproxy-2.2

I’m not sure I can help you myself. Its probably better if you just file a bug at github:

Understood. I opened https://github.com/haproxy/haproxy/issues/822

1 Like