Solved Many TCP connections -> FreeBSD networking unreachable

maxconn setting in HAProxy has nothing to do with the listen queue length. TCP connections will start filling up the listen queue if the process can't pick up those connection requests fast enough. As long as HAProxy is able to pick up the connection (up to maxconn) there shouldn't be anything getting queued.

Things might start stalling if the backends can't process the requests fast enough. But that's what HAProxy is for, to spead the load over multiple backends. Each backend can be given a certain 'weight', that defines how much of the traffic it gets assigned. So if you have two backend servers, each with a weight of 100, they both get an equal amount of traffic to process. If one is 50 and the other 100, the 50 server will get roughly 1/3 of the traffic and 2/3 will go to the other server. If your backend still can't handle the load it's time to add more backend servers.

With the check scripts you can even make the 'weight' dynamically adjustable. So if one server starts having problems it can signal to HAProxy to reduce its weight, so it gets less traffic assigned.
 
Does it mean that it is unnecessary to increase kernel.ipc.somaxconn value (it's 128 by default) to maxconn value (in my case it was 2000)?

OP states the OS is unresponsive not the HAProxy is sluggish.
 
I have HAProxy's maxconn set at 35000 and kern.ipc.somaxconn is still default. Never had an issue with that. At the moment our HAProxy setup doesn't get as much traffic as a few years ago but the listen queue was never an issue. We're currently handling around 1200 concurrent connections but that number was much larger a few years back.
 
There is no 12/release. There is 12.2-RELEASE (releng/12.2), which the OP is apparently having problems with.
 
Back
Top