sysctl kern.ipc.somaxconn limit 65535 why?

Chuck Swiger cswiger at
Wed Jan 4 22:11:12 UTC 2012

On Jan 4, 2012, at 1:49 PM, Arnaud Lacombe wrote:
> Hi,
> On Wed, Jan 4, 2012 at 4:42 PM, Chuck Swiger <cswiger at> wrote:
>> On Jan 4, 2012, at 1:03 PM, Dan The Man wrote:
>>>> However, I'm not convinced that it is useful to do this.  At some point, you are better off timing out and retrying via exponential backoff than you are queuing hundreds of thousands of connections in the hopes that they will eventually be serviced by something sometime considerably later.
>>> I agree completely, in practical application this makes sense, but why should the OS dictate not being able to temporarily set that setting higher in order to fully benchmark the application at 100k+ in the listen queue if the developer so chooses? I think that alone should be a good reason, to make freebsd developer friendly.
>> The job of the OS is to manage resources on behalf of the users and processes using the system.
> No. The job of the OS is to service the user with the resource
> available, not constrict the user within some arbitrary predefined
> wall when there is still plenty of room available. If resource become
> scarce, then take action.

It is not arbitrary.  Systems ought to provide sensible limits, which can be adjusted if needed and appropriate.  The fact that a system might have 50,000 file descriptors globally available does not mean that it would be OK for any random process to consume half of them, even if there is still adequate room left for other tasks.  It's common for "ulimit -n" to be set to 256 or 1024.

>> Some developers feel that VM means that the system should always claim have more memory available, but always saying "yes" isn't "managing resources".  I'd rather have the OS return a null pointer and set ENOMEM when someone tries to malloc() more memory than the system (including swap, VM overcommit, etc) has, and I expect developers to code well enough to handle malloc() failures.
> this is merely a policy issue, not yours to impose.

If we're speaking of machines which I administer, it is a policy issue that would be mine to impose.
If we're speaking of someone else's machines, then they can set their own policies as they please.

>> Setting the listen queue to an arbitrarily high value isn't useful, and developers would be better advised to pay attention to best practices in the face of a massive connection backlog.
> Stress-testing isn't about "best practice". It is about shaking enough
> the system to highlight weak point.

Yes.  If the system doesn't handle connectivity problems via something like exponential backoff, then the weak point is poor software design and not FreeBSD being unwilling to set the socket listen queue to a value in the hundreds of thousands.


More information about the freebsd-current mailing list