Re: sysctl kern.ipc.somaxconn limit 65535 why?

Hi,

On Wed, Oct 03, 2012 at 10:15:32PM +0200, Andre Oppermann wrote:
> 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.

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.