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

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.

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.

>  I cant tell app developers to
>fix their apps to work on FreeBSD, they dont care, if it works fine on
>windows and linux then the app isnt broken as far as they are concerned.

FreeBSD is not Windows or Linux and never will be.  There are lots of
grey areas in the various standards that *BSD, Linux, Solaris, Windows
etc comply with and some OSs interpret these grey areas differently to
others (in some areas, it seems Linux has deliberately done things
differently to other Unices for no obvious reason, and the GNU
embrace-and-extend philosophy doesn't help).  Writing portable code
takes more than adding some .ac/.am files to an arbitrary blob of code
and just because a developer thinks their app isn't broken doesn't
make them right.

BTW, I note that this was sent to -current?  Are you running HEAD on
production servers?  If so, your feedback on issues you encounter
would be appreciated so that they can be corrected before they make
it into a RELEASE.

-- 
Peter Jeremy