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

On Fri, Oct 05, 2012 at 08:21:53AM +1000, Peter Jeremy wrote:
> On 2012-Oct-03 19:45:01 +0100, freebsd_at_chrysalisnet.org wrote:
> >In addition we had to migrate all our mysql servers from freebsd to debian
> >because they were hitting some arbitary OS limit but I could never figure
> >out what, sys% usage went through the roof when this limit was hit, issue
> >didnt occur on debian.

It's a well known point that linux isn't serving time correctly
where FreeBSD requires much more load to do it right.
It is also well known that MySQL asks for time horrible often.
Don't know what they expect this to serve, when it's either slow or
wrong, but they do it.
Maybe we have hacked around this issue - there are lots of people
doing workload tests comparing Databases on Linux and FreeBSD and
in the end it always is more or less equal when everything is
configured right.
Our installed defaults for MySQL migh be different than with
Debian and also OS tuning is very different.
Sometimes even hardware selection can make big difference when
comparing OS, if one OS has a slow driver for a given hardware,
or one has a lazy driver ignoring data consistency.

> Did you report this issue on any of the FreeBSD mailing lists?
> Reporting a problem doesn't guarantee that it will be fixed
> (unfortunately) but not reporting a problem makes it extremely
> unlikely that it will be fixed.
> 
> >  I feel recently freebsd is more focused on desktop's
> >and as such developer's never develop for a heavy server usage scenario,
> 
> This isn't intentionally true but it's true that few developers run
> large servers so they may not run into some issues that only impact
> large systems.  Again, it's up to people who do run such systems to
> provide feedback about bottlenecks & issues they hit so that they can
> be fixed.
> 
> >I keep coming across hardcoded low limits.  As rightly pointed out default
> 
> There are lots of defaults that were set some time (potentially
> decades) ago and may no longer be optimal.  It's unrealistic to expect
> that all the defaults are correct in all circumstances and this is one
> area where end users can help by flagging defaults that they find need
> tuning.
> 
> >values now days are useless 128 for somaxconn? maybe ok for a desktop.
> 
> But, as others have pointed out, this isn't one of them.  Can you
> please provide more details on a use scenario where a listen(2)
> backlog exceeding 128 is reasonable.

It's simple math.
If the accept loop sleeps for 1 second a connection backlog of 128
ist good for 128 connections per second.
However accept loops sleeping for 1 second for high rate servers
mean there is something programmed wrong - more likely accept loops
sleep for 1-5ms, so 128 is good for at least 25600 connetions per
second.
Requiring more than 65536 with well done programming means that
you try to handle more than 13107200 connections per second.
Such a connection rate sounds even unlikely given the number of
IP packets required on the network interface just to establish the
connections.
Furthermore - the typical high transaction service these days are
webservers and there you can benefit from keepalive very much.
If on the other hand your well written accept loop isn't fast
enough because of high CPU load, then the machine is simply overloaded
and queuing more connections won't serve you anything but changing
symptoms.
In any case it ends in bad programming or extremly untypical use case.
Yes - we do not support bad programmed applications or every
imaginable extreme use case out of the box, that's right.

-- 
B.Walter <bernd_at_bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.