Date: Wed, 30 Jun 2004 12:48:31 -0700 (PDT) From: Mark Terribile <materribile@yahoo.com> To: freebsd-questions@freebsd.org, Steve Bertrand <iaccounts@ibctech.ca> Subject: Re: kern.ipc.nmbclusters Message-ID: <20040630194831.97385.qmail@web21105.mail.yahoo.com> In-Reply-To: <20040630190746.1EE2016A4DF@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Bertrand <iaccounts@ibctech.ca> writes:
> I have a machine that is rebooting with the following error:
>
> "All mbuf clusters exhausted, please see tuning(7)."
>
> Which through google and man tuning I was able to figure out that indeed,
> mbufs were exhausted. So I tried to set kern.ipc.nmbclusters=4096 (which
> should cover the load of the server), but found out after it is not a
> run-time tunable parameter.
This doesn't answer the question asked, but it may be useful. A few years
ago (and a few releases ago) I was working on a network box that had to run
under fairly heavy load. This was a product, and we were not satisfied
with less than 100% CPU, about 6000 network stimuli/second, about 220
transaction/sec on each of five disks, etc. (On a 1GHz PIII)
I discovered that I couldn't make the mbuf cluster number large enough,
and that the system was prone to panic under sufficiently heavy load.
Sufficiently heavy meant that we had tens of seconds of traffic queued.
The solution was to shorten the TCP listen/accept queues. I cut them down
to six on each file descriptor, and used kqueue/kevent (then just introduced)
to schedule the work intelligently. I was able to push the box to near
paralysis with 80% overload (most of it rejected because the input queues
were full) but the box always recovered, and it ran at 10% overload with
only a small latency degradation.
The max accept queue parameter may be worth a look; YMMV.
Mark Terribile
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040630194831.97385.qmail>