Date: Sat, 14 Dec 2002 14:33:37 -0800 (PST) From: Mike Hoskins <mike@adept.org> To: freebsd-stable@freebsd.org Subject: Re: Performance tuning on -stable for a dummy :) Message-ID: <20021214140815.G9387-100000@fubar.adept.org> In-Reply-To: <20021214214200.18355.qmail@web20706.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 14 Dec 2002, John Merryweather Cooper wrote:
> I presume you've done a
> $ man tuning
Hmm, I believe his first mail indicated he'd taken a look at tuning.
There was mention of netstat earlier... Notice the output format,
130/464/26624 mbufs in use (current/peak/max):
129 mbufs allocated to data
1 mbufs allocated to packet headers
128/228/6656 mbuf clusters in use (current/peak/max)
572 Kbytes allocated to network (2% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
So you can keep on eye on "peak" usage under load. (If peak routinely
equals max... You need to allocate more!)
> But before one gets to tweaking things, I think it's
> good practice to strip down the kernel to what you
<snip>
> weight. This is particularly true of CPU support your
> system doesn't need.
Indeed, I think too many people overlook this (relatively) easy task.
Specifically, ensure I386_CPU is not in your kernel config. :)
> doesn't occur. Note that it may be desirable to
> increase physical memory since 4.7-STABLE does some
> default tuning itself depending on available memory.
And in that case "maxusers 0" may be desireable. (Auto-size based on
physical memory.) LINT explains all of this.
> > network. And Java always seems to use an unusually
> > high amount of
> > memory even when the server isn't loaded heavily.
I've seen similar memory usage patterns with Sun's and IBM's JDKs on
Linux. (Yeah, I have to support it... Not my choice. :) JVMs and OSs
like to cache things in memory, so this isn't necessarily bad. During
peak load, take a look at some vmstat output and identify if there's
excessive amounts of swapping going on. Take care to disregard the first
column of vmstat output, as it is a running average since boot.
> > > > kern.ipc.nmbuffers=65536
> > > > kern.ipc.maxsocbuf=2097152
> > > > kern.ipc.somaxconn=8192
> > > > kern.ipc.maxsockets=16424
> > > > kern.maxfiles=65536
> > > > kern.maxfilesperproc=32768
> > > > etc,etc
This seems a bit excessive. :) But you know best, as it is your
machine/application. That said, specificaly note this snippet from
tuning(7):
kern.ipc.nmbclusters may be adjusted to increase the number of
network mbufs the system is willing to allocate. Each cluster
represents approx imately 2K of memory, so a value of 1024 represents
2M of kernel memory reserved for network buffers.
I don't see nmbclusters in your list of definitions above (although it may
be implied by etc,etc...) Heavily loaded servers should most certainly
set this. I do it via loader.conf,
mike@eng{mike}$ cat /boot/loader.conf
kern.ipc.nmbclusters=32768
> > > > What is a good /boot/loader.conf for a someone
> > like
> > > > me? I don't totally
> > > > understand all of the tunables. Is there a good
The best thing to do is to either slowly increase values and observe the
results under load as another indicated (some people do this on
production servers, and call this "hot tuning"), or to set very high
values on test servers and see what's actually used under load... (I
prefer testing everything in QA before touching production... But a
QA environment isn't always available.) Then tune parameters down as much
as possible, saving kernel memory, etc.
At this point in the tuning game, most of the things you'll be tweaking
will be relatively specific to your site... so generic examples may be of
minimal use. Take a lookt at bsdforums.org. Do a search for 'tuning' and
you should find some real-world examples of what people are using (plus
you can create an account and ask them why, etc).
Good luck,
--
Mike Hoskins This message is RFC 1855 compliant,
mike@adept.org www.adept.org/pub/rfcs/rfc1855.html
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021214140815.G9387-100000>