From owner-freebsd-database Thu Oct 28 10:48:33 1999 Delivered-To: freebsd-database@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id EAD92151C6; Thu, 28 Oct 1999 10:48:28 -0700 (PDT) (envelope-from steveb@veriohosting.com) Received: by gatekeeper.veriohosting.com; Thu, 28 Oct 1999 11:48:25 -0600 (MDT) Received: from unknown(192.168.1.7) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma012904; Thu, 28 Oct 99 11:48:07 -0600 Received: from iserver.com (glacier.orem.iserver.com [192.168.1.111]) by orca.orem.veriohosting.com [Verio Web Hosting, Inc. 801.437.0200] (8.8.8) id LAA59123; Thu, 28 Oct 1999 11:49:20 -0600 (MDT) Message-ID: <38188BEC.75ABC44D@iserver.com> Date: Thu, 28 Oct 1999 11:46:21 -0600 From: Steve Bishop X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-database@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Cc: "Paul.Marquess@btinternet.com" Subject: Re: mbuf problem (panic) SOLVED --possibly related to Berkeley DB 2.7.7 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-database@FreeBSD.ORG Precedence: bulk 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-database" in the body of the message