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

On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd <adrian_at_freebsd.org> wrote:
> Hi,
>
> 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.

    Or the TTL of TCP connections might be too high for the volume of
connections received. Someone else on net_at_ reported that changing this
value to more aggressively reap sockets improved performance greatly
(at the cost that more connections potentially needing to be
reestablished and/or getting dropped on the floor if things go too
high volume).
    But yeah... the listen(2) queue might be too high, or the
application might be accept(2)'ing too much and thus the queue is
backing up too much. I was merely providing the pointer to "why"
things are the way they are.
Thanks,
Garrett "so many knobs, so little time" Cooper