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>