Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Nov 2012 08:52:48 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Alfred Perlstein <bright@mu.org>
Cc:        svn-src-head@freebsd.org, Alexey Dokuchaev <danfe@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, Peter Wemm <peter@wemm.org>
Subject:   Re: svn commit: r242847 - in head/sys: i386/include kern
Message-ID:  <CAJ-Vmo=FZy1B50Qt%2BmGWgOVH_hmXBCxyO8Bv_wBLn95HG_Wfvw@mail.gmail.com>
In-Reply-To: <509F72B0.90201@mu.org>
References:  <CAF6rxg=HPmQS1T-LFsZ=DuKEqH30iJFpkz%2BJGhLr4OBL8nohjg@mail.gmail.com> <509DC25E.5030306@mu.org> <509E3162.5020702@FreeBSD.org> <509E7E7C.9000104@mu.org> <CAF6rxgmV8dx-gsQceQKuMQEsJ%2BGkExcKYxEvQ3kY%2B5_nSjvA3w@mail.gmail.com> <509E830D.5080006@mu.org> <1352568275.17290.85.camel@revolution.hippie.lan> <CAGE5yCp4N7fML05-Tomm0TM-ROBSka5%2Bb9EKJTFR%2ByUpFuGj5Q@mail.gmail.com> <20121111061517.H1208@besplex.bde.org> <CAGE5yCpExfeJHeUuO0FEEFMgeNzftaFSWT=D-yKGdP%2B1xnjZ4A@mail.gmail.com> <20121111073352.GA96046@FreeBSD.org> <509F72B0.90201@mu.org>

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

You're thinking about it one step ahead, not 5 steps ahead.

One step ahead: "let's fix maxuser scaling."

5 steps ahead: "Let's find all of the non-dynamic things that maxusers
scales, figure out how to make them run-time tunable, and then make a
maxusers.sh user-land script that scales these values when you type
'maxusers 512'."

Then you can fiddle in userland in your hearts content with how to
scale these things.

The only recent time I've seen the need for ridiculously large
non-default values for mbuf clusters is for one of the 10ge NICs that
preallocates them at device startup time, and fails to attach right if
they're not all available.

With everything dynamically tunable and the maxusers script in
userland, you can:

* fondle the curves as you want;
* export usage stats for all the things that the above tuning does
affect (which you've been doing with netstat and mbuf allocation
hangs, thankyou!)
* start looking at providing much better inspection and auto-tuning
tools, which allow the sysadmin to actually start controlling what
spirally death their server decides to visit, versus just "spirally
death."




Adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=FZy1B50Qt%2BmGWgOVH_hmXBCxyO8Bv_wBLn95HG_Wfvw>