Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Dec 2001 12:12:45 +0100
From:      Andre Oppermann <oppermann@pipeline.ch>
To:        Mike Silbersack <silby@silby.com>
Cc:        net@freebsd.org, David Xu <davidx@viasoft.com.cn>, Mike Barcroft <mike@FreeBSD.ORG>, Leo Bicknell <bicknell@ufp.org>
Subject:   Re: mbuf / maxfiles / maxsockets / etc autoscaling patch
Message-ID:  <3C1498AD.E9B53A10@pipeline.ch>
References:  <Pine.BSF.4.30.0112081756370.61906-200000@niwun.pair.com>

next in thread | previous in thread | raw e-mail | index | archive | help

Cool stuff and overdue for a loooong time!

A few comments on the code:

 - IMHO it would be helpful to print the chosen values into the boot
   dmesg (maybe larger parts of it only with verbose). This aids
   explaining strange symtoms if someone adds/removes RAM and is not
   aware of autoscaling. "I took out 128MB of RAM and my webserver
   starts to fail..."

    Autoscaling enabled, setting values based on 64MB of usable RAM
    Autoscaling mproc=1024, mfiles=8192, msocket=4096, callout=9232,
    nmbcl=2048, nsfbuf=1024, tcphashsize=512

 - I would suggest to append "MIN|MAX" to the variable instead of
   prepending it

    +#define TCBHASHPERMB 8
    +#define TCBHASHAUTOMIN 512
    +#define TCBHASHAUTOMAX 8192

 - An update to the tuning man page describing this autoscaling is
   missing from this patch.

-- 
Andre


Mike Silbersack wrote:
> 
> Here's the autoscaling patch I was mumbling about earlier this week.
> With this patch applied, the necessity of tuning maxusers when one
> upgrades to a machine with more ram should be removed in most cases.
> (This patch is only to -current, the mbuf changes will make it not apply
> cleanly to -stable patch if there is sufficient demand right now.)
> 
> Here's a quick look at the size of various memory allocations with various
> maxusers sizes and with the autoscaling patch:
> 
> With maxusers:
> 
> musers  mproc   mfiles  msocket callout nmbcl   nsfbuf  tcp hash size
> 32      532     1064    1064    1612    1024    1024    512
> 64      1044    2088    2088    3148    1536    1536    512
> 128     2068    4136    4136    6220    2560    2560    512
> 256     4116    8232    8232    12364   4608    4608    512
> 
> With autoscaling:
> 
> MB ram  mproc   mfiles  msocket callout nmbcl   nsfbuf  tcp hash size
> 32      512     4096    2048    4624    1024    1024    512
> 64      1024    8192    4096    9232    2048    1024    512
> 128     2048    16384   8192    18448   4096    2048    1024
> 256     4096    32768   16384   36880   8192    4096    2048
> 384     6144    49152   24576   55312   12288   6144    3072
> 512     8192    65536   32767   73744   16384   8192    4096
> (Values above this start to flatten out due to #defined maximums)
> 
> Note that in general calculations are of the following form:
> 
> value = max(maxusers-derived value, autoscale-derived value);
> value = loader tuned value if present
> 
> As such, under no circumstances will people suddenly see a decrease in
> various parameters when they upgrade to an autoscaling kernel; only
> increases.
> 
> I'm sure that there will be much commotion about what scaling factors are
> correct.  To make changes to these easy, I have grouped all the mins,
> scaling factors, and maxes in param.h - tweaking them is quite simple.
> 
> I included mins and maxes to make sure that autoscaling doesn't cause
> problems by creating low values on small memory machines and also so that
> it does not specify really high values on 2GB+ machines.  The high case is
> what worries me; I have not heard much about how well maxsockets /
> nmbclusters > 32767 really works.  If people running high volume systems
> that actively use that many simultaneous sockets + clusters + files, I'd
> be glad to bump up the maxes.
> 
> Oh, there's one more kicker thrown in; I changed maxfilesperproc to equal
> 9/10ths of maxfiles, and maxprocperuid to equal 9/10 maxproc; this'll help
> to prevent a single process or user from forkbombing the system or running
> it out of file handles with a default configuration.
> 
> Please review.
> 
> Thanks,
> 
> Mike "Silby" Silbersack
> 
>   ------------------------------------------------------------------------
>                       Name: autoscale.patch
>    autoscale.patch    Type: Plain Text (TEXT/PLAIN)
>                   Encoding: BASE64

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C1498AD.E9B53A10>