Hi Jeremie Le Hen! On Mon, 8 Oct 2012 12:49:34 +0200; Jeremie Le Hen wrote about 'Re: sysctl kern.ipc.somaxconn limit 65535 why?':
>> On 03.10.2012 22:03, Adrian Chadd wrote: >>> >>> somaxconn is the connection queue depth. If it's sitting at a couple >>> hundred thousand then something else is going crazily wrong. >>> >>> I understand your frustration, but there's a lot of instances where >>> the application just isn't doing things "right" and the OS tries to >>> hide it as much as psosible. Blowing out somaxconn to chew up a whole >>> lot of resources seems a bit silly. I'd rather investigate why the >>> userland application is not servicing the connect queue often enough. >>> >>> I've written network services that supported tens of thousands of new >>> TCP connections a second on a LAN and I never once had to bump >>> somaxconn past 32767. I'm not saying that it won't apply to your >>> scenario, I'm just trying to explain that there's likely more going >>> on. >> >> I guess the problem is rather kern.ipc.maxsockets which is only 25600. >> >> The name somaxconn is confusing as it specifies the listen queue limit >> instead of the maximum number of connections as the it suggests. > If we want to change that name to something more sensible and less > error-prone like "somaxbacklog", does the project has a policy to change > sysctl names? > I'm thinking of something like renaming the sysctl to "somaxbacklog" and > make "somaxconn" compatibility shim during RELENG_10 which still works > but prints a warning in the dmesg. AFAIR, the policy was to keep for two major releases, not one, though it was the policy for binaries, not sysctl (e.g. if /sbin/natd would be officially made deprecated in 10.0 RELNOTES, then it must be kept in 10.* and 11.* with complete removal in 12.0). Possibly the policy for sysctl's is the same, because 3rd-party software may use such knobs, while not sure this applies to kern.*, though. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com] _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
