sysctl kern.ipc.somaxconn limit 65535 why?
delphij at delphij.net
Thu Jan 5 02:06:19 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 01/04/12 17:49, Chuck Swiger wrote:
> Hi, Xin--
> On Jan 4, 2012, at 5:32 PM, Xin Li wrote:
>> I am personally quite convinced that FreeBSD should make such
>> change though -- having more than 64K of outstanding and
>> unhandled connections does not sound a great idea (i.e. it's not
>> a connection limit after all, but the pending handle connection.
>> If my math were right, 64K connections would require about 1Gbps
>> bandwidth in and out if they happen in the same second.) But I
>> agree this would be a good stress test, which might expose some
>> bugs we don't know today.
> I think I agree with the change from a correctness standpoint--
> listen(2) accepts an int backlog argument.
> I'm not convinced that there are many scenarios where needing to
> exceed a listen queue backlog of 64K would be beneficial to a
> real-world system, and I am sure there are many scenarios where it
> would be counterproductive, but folks can adjust kern.ipc.somaxconn
> as they see fit and perhaps Dan or others would gain some value
> from it.
Ah sorry that should read something like "I'm not quite convinced" and
as you see I were explaining why in detail but apparently I missed to
check the spellings...
Xin LI <delphij at delphij.net> https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the freebsd-current