Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Oct 1999 11:46:21 -0600
From:      Steve Bishop <steveb@veriohosting.com>
To:        freebsd-database@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Cc:        "Paul.Marquess@btinternet.com" <Paul.Marquess@btinternet.com>
Subject:   Re: mbuf problem (panic) SOLVED --possibly related to Berkeley DB 2.7.7
Message-ID:  <38188BEC.75ABC44D@iserver.com>
References:  <Pine.BSF.4.05.9910261942280.26596-100000@misery.sdf.com>

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

I've increased maxusers to 512, and NMBCLUSTERS to 16384, and I  haven't
been able to reproduce the kernel panic problem anymore.

So, my conclusion is that increasing maxusers solved the problem.
I don't believe that raising NMBCLUSTERS by itself, or it indirectly being
raised by maxusers, fixed the problem.  The reason I think this
is because I raised NMBCLUSTERS to 8192 before, and it had  no effect
whatsover in delaying or preventing the kernel panics I was experiencing.
 As I described before, right before the panic occurred, the OS
began to exponentially use up all of the mbufs, and even if I had set
NBMCLUSTERS to 30000 it would have used them up in short order.

The typical mbuf usage for this system while running all of its software (scripts)
is about 100 mbufs, and it has been running over a day now, and not exceeded
962.  I've not seen anywhere near the kind of mbuf usage, that occurred when
the machine panicked before.

This leads me to the conclusion that maxusers, affects many other kernel parameters
(which of course it does),
and indirectly eliminated the mbuf problem by providing enough resources for the database
in all situations, and most especially in cases when Berkeley DB wasn't shut down clean,
or in its proper fashion.

Although I don't know all of the kernel parameters affected by increasing maxusers,
it seems to have solved my problem, and in a roundabout way prevented the machine
going into its "spiral-of-death" mbuf problem.

-Steve
Developer
Verio, Inc.

verio.com  -- the new world of business





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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38188BEC.75ABC44D>