Hello James,
On Thu, Mar 05, 2020 at 06:36:15PM +, James Stroehmann wrote:
> Maxconn default seems to be set to 2000 in the version 1.7 servers we are
> running, but in the 2.0 server it looks like the default is 114:
>
> The 2.0 management guide
> (https://cbonte.github.io/haproxy-dconv/2.0/management.html) shows output
> from version 1.6, I'm wondering why such a low number for default?
It's not a lower default, it's that before 2.0 it used to *try* to
apply the default value, and adjust ulimit-n accordingly, which used
to fail in a number of environments, and was a real pain to properly
configure in others (since it would require to explicitly set maxconn
while the ulimit-n was already raised at the system level). In addition
this default value of 2000 was bad for everyone: small users usually
didn't have the permissions to raise ulimit-n and used to experience
various runtime failure (lack of FD to connect to a server or to run
a health check for example), and large users didn't notice they were
limited because 2000 is quite enough for unit tests but not for most
sites' peak traffic.
Since 2.0 it does it backwards now: if you don't set maxconn, it checks
the existing ulimit-n, deduces all FDs already in use (listeners, epoll,
stdin/out etc) and computes the resulting maxconn. This one is guaranteed
to fit within the limits assigned to the process. In your case your
process is limited to 1023 and you probably have a large number of
servers and/or listeners, which means that you may have a number of
FDs which are already reserved and that's what is guaranteed to work
once all this is deduced.
This just makes me think that we could improve the situation a little
bit by relying on the process' hard limit and not the soft limit, as
currently we may possibly not use as many FDs as we could use before.
Could you try the current patch ? For me as an unprivileged user, it
raises my default maxconn from 488 to 2024 since I'm running with
1024/4096:
diff --git a/src/haproxy.c b/src/haproxy.c
index 759612dfd8..c7905a52e4 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -1417,7 +1417,7 @@ static int compute_ideal_maxconn()
int ssl_sides = !!global.ssl_used_frontend + !!global.ssl_used_backend;
int engine_fds = global.ssl_used_async_engines * ssl_sides;
int pipes = compute_ideal_maxpipes();
- int remain = rlim_fd_cur_at_boot;
+ int remain = MAX(rlim_fd_cur_at_boot, rlim_fd_max_at_boot);
int maxconn;
/* we have to take into account these elements :
I think we should do that and backport it to make sure that *any*
previously working default setup continues to work with the same
level of guaranteed limits (i.e. before service was degraded).
Thanks,
Willy
