Date: Tue, 26 Oct 1999 14:13:31 -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: mbuf problem (panic)--possibly related to Berkeley DB 2.7.7 Message-ID: <38160B6A.5568F6D1@iserver.com>
next in thread | raw e-mail | index | archive | help
I am using FreeBSD 3.3-RELEASE, and it is running on a single processor PII 400.
At first, I thought the problem was due to the network driver, so I swapped network
cards. But, the problem still continues to occur. At first, I used a DEC (de0) NIC.
Then, I switched to an Intel EtherExpress Pro 10/100B Ethernet (fxp0).
My machine dies when it runs out of mbufs. Normally, one only associates mbufs with
network usage, and network (NIC) drivers. I have tried to investigate this possibility,
as mentioned, but to no avail.
The problem is either a kernel problem, or is related to the Berkeley DB, and/or
perl module - BerkeleyDB-0.07.pm. I have written to Paul Marquess who is the
author of this perl module. He did not respond, and may not have any idea. The latest
release of this perl module is a significant update to the perl support for the latest releases of Berkeley DB.
It provides for concurrency and database integrity (consistency) between processes sharing
or using the same database simultaneously.
There are a number of scripts, I have written, in the system that run (as processes) in parallel.
This is why I am using the Concurrent Access Method (CAM) to allow multiple simultaneous
readers along with sequential write (one writer at a time) access. Berkeley DB keeps everything
consistent.
The scripts are designed to use the database a lot, and they also use a significant amount
of network resources. The scripts sometimes can have up to 900 open tcp connections,
and consistently use almost 600. I have increased the number of mbuf clusters (NMBCLUSTERS)
from 1024 to 4096. I have also increased maxusers to 64.
The "panics" seem to occur when my scripts or processes prematurely exit without
shutting down Berkeley DB in the standard, proper fashion.
As I explained, I have upped the number of mbuf clusters from the default 1024, to 4096. The actual number
probably wouldn't matter a whole lot as long as it is sufficient to meet the needs of the system were being met.
What I'm trying to say, is that when the script(s) crash, the system then begins to use mbufs exponentially,
until they're completely exhausted within minutes. The system panics, and reboots.
I know the association is loose, but nothing else presents itself as the problem. Is there some kernel
resource that Berkeley DB gets a hold of, and never properly releases due to an improper, fatal termination
of my script, which could indirectly cause my system to run out of mbufs? I know that the close_everything
routine in BerkeleyDB.pm still runs when perl exits, but perhaps, it doesn't work properly in this case?
Any ideas or leads as to why this is occuring would be sincerely appreciated.
Thanks,
Steve Bishop
Developer
Verio, Inc.
verio.com -- the new world of business
PS Here's some more background info.
In perl, to setup Berkeley DB, I use the shared memory pool. Here is how I setup the
environment, and open my database.
$env = new BerkeleyDB::Env -Flags => DB_CREATE| DB_INIT_MPOOL| DB_INIT_CDB,
-ErrFile => "db-errors";
$DB = tie %db, 'BerkeleyDB::Btree', -Filename => 'servers.db',
-Mode => 0600,
-Flags => DB_CREATE,
-Pagesize => 4096, # default = 8192
-Env => $env
or
die "Cannot open db: $! $BerkeleyDB::Error";
I think I have discovered an association between my system crashes ("out of mbufs"), and the
usage of Berkeley DB.
When my script prematurely crashes or exits without following the proper database shutdown
procedure, as outlined below, it isn't very long before the machine crashes (usually a few minutes).
undef($DB);
undef($env);
untie(%db);
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-database" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38160B6A.5568F6D1>