Don't limit the backlog for listen(2)

[Al2Klimov]

No description provided.

[dnsmichi]

I'm not sure if this will help with the current problems in slowly processing the requests. This will increase the backlog and likely harm the possibility to just retry the request by the client when it gets 'connection refused' instead.

https://serverfault.com/questions/518862/will-increasing-net-core-somaxconn-make-a-difference

Some administrators use high net.core.somaxconn to hide problems with their services, so from user's point of view process it'll look like a latency spike instead of connection interrupted/timeout (controlled by net.ipv4.tcp_abort_on_overflow in Linux).

listen(2) manual says - net.core.somaxconn acts only upper boundary for an application which is free to choose something smaller (usually set in app's config). Though some apps just use listen(fd, -1) which means set backlog to the max value allowed by system.

Real cause is either slow processing rate (e.g. a single threaded blocking server) or insufficient number of worker threads/processes (e.g. multi- process/threaded blocking software like apache/tomcat)

@lippserd I'd leave this "as is".

[Al2Klimov]

It's unlikely to help with the current problems, but IMO the admins shall be able to decide by themselves what's good for them.

[Al2Klimov]

Substituted by #7005.