Date: Tue, 9 Oct 2012 09:31:42 +0000 (UTC) From: Vadim Goncharov <vadim_nuclight@mail.ru> To: freebsd-current@freebsd.org Subject: deprecation policy (Was: sysctl kern.ipc.somaxconn limit 65535 why?) Message-ID: <slrnk77rnv.ci7.vadim_nuclight@kernblitz.nuclight.ipfw.ru> References: <03e101cda197$326dc240$974946c0$@org> <CAJ-Vmo=CtC1SpsedP3nHJsrApTLzktGrjopeV0vXShr0FOUsmA@mail.gmail.com> <506C9CE4.6080400@freebsd.org> <20121008104934.GB25291@felucia.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnk77rnv.ci7.vadim_nuclight>