Chris,
Your email prompted me to look at mbuf utilization on a 4.1.1-STABLE box
that is currently not in production.
outside# netstat -m
130/160/7168 mbufs in use (current/peak/max):
129 mbufs allocated to data
1 mbufs allocated to packet headers
128/136/1792 mbuf clusters in use (current/peak/max)
312 Kbytes allocated to network (92% in use)
^^^^^^^^^^
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
outside# uptime
4:32AM up 1 day, 14:01, 1 user, load averages: 0.00, 0.00, 0.00
I don't know whether to be concerned about the 92% utilization since the
number of bytes allocated seems low. The machine has never crashed but then
it has never served as a server.
Is this kind of mbuf utilization expected?
Kent Kuriyama
SPAWAR Sys Ctr San Diego D424, CINCPACFLT N671KK
[EMAIL PROTECTED], 808-471-4125
-----Original Message-----
From: Chris BeHanna [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2000 01:15 AM
To: FreeBSD-Stable
Subject: mbuf leakage on 4.1.1-STABLE
I posted a week or two ago about my machine wedging every couple
of days, and seeing RX packet drop messages due to no memory
available in /var/log/messages. Specifically, the messages were
"dhclient: send_packet: No buffer space available
/kernel: xl0: no memory for rx list -- packet dropped!"
repeated thousands of times.
Sean O'Connell pointed me in the right direction, stating that
this looked like an mbuf starvation problem. I've been checking my
system constantly via netstat -m, and it looks like I'm leaking mbufs
(mbufs in use and mbuf clusters in use increase until they hit their
limit, then the machine freezes, waiting, I suppose, for an mbuf to
become available). I've taken an interim measure of doubling the
number of NMBCLUSTERS in my kernel, but that just puts off the
inevitable. I end up rebooting when I'm at 80% mbuf cluster usage, so
that I can avoid having to fsck my disks when the machine wedges and I
have to hit the button.
A friend of mine suggested that I instrument mbuf.h and
uipc_mbuf.c so that I could see where all of the allocs and frees
occur. I've looked through these files, and it's not immediately
obvious to me just how I'd instrument them to do that (e.g., __FILE__
and __LINE__ obviously can't be used).
For reference, I'm running 4.1.1-STABLE, cvsup'ed early on October
4th or late on October 3rd, and my NIC is a 3Com 3C905B. I've been
seeing this problem for some time now, but it's gotten a lot worse
recently, and I'm given to understand that it could be just about
anywhere in the protocol stack, not necessarily in the xl driver.
I am willing to do some work to debug this, but never having been
a kernel hacker, I need a little bit of guidance.
Help! My Linux-using co-workers are really giving me the business
over this!
Thanks,
--
Chris BeHanna
Software Engineer (at yourfit.com)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
