Date: Fri, 10 May 1996 14:47:38 -0400 From: Garrett Wollman <wollman@lcs.mit.edu> To: sameer <sameer@c2.org> Cc: freebsd-questions@freebsd.org Subject: mb_map full and looking at that table Message-ID: <9605101847.AA28294@halloran-eldar.lcs.mit.edu> In-Reply-To: <199605101701.KAA29848@infinity.c2.org> References: <199605101701.KAA29848@infinity.c2.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Fri, 10 May 1996 10:00:50 -0700 (PDT), sameer <sameer@c2.org> said:
> I had mb_map full so I checked the archive and have set
> NMBCLUSTERS to a higher value. Hopefully that will fix it. My question
> is how do I monitor the size of the mb_map so I know when to increase
> it without having to wait until I get that error again?
This depends on what version you are running. In all cases, you can
monitor the number of mbuf clusters currently allocated (and the
high-water mark) with `netstat -m':
------------------------------------
13 mbufs in use:
1 mbufs allocated to data
1 mbufs allocated to packet headers
7 mbufs allocated to protocol control blocks
4 mbufs allocated to socket names and addresses
0/12 mbuf clusters in use
^^^^^^^^^^^^^^^^^^^^^^^^^ this line
25 Kbytes allocated to network (6% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
------------------------------------
However, if you are running -current, a recent change to the way mbufs
are allocated has significantly confused the situation. (I have a fix
for the confusion which I have to test out.) The mbuf allocator was
changed to allocate regular mbufs from the same kernel memory space as
clusters were allocated from. But, the calculation of how much space
to allow to be allocated was not modified. So, if your value of
NMBCLUSTERS was X, you could only hold about X - X/8 packets in memory
where previously you could hold X plus quite a bit more (up to 60% of
kernel memory minus 256*X).
The fix will be to allocate mbufs and mbuf clusters out of different
kernel memory maps. The existing mbuf cluster map will be the same
size as before, and the new `regular mbuf map' will either by the
same size in bytes, or some other value heuristically related to
NMBCLUSTERS and/or MAXUSERS. (I'm leaning now towards the former.)
This will allow you to allocate up to 3648*NMBCLUSTERS bytes maximum
for network data (not including the space required for controrol
information), and makes it easier by far to tune the limits. I could,
in theory, simply increase the size of the existing map and allocate
both out of the same space, but this breaks the automatic fall-over
from clusters to regular mbufs when clusters are exhausted. (There
may well be other parts of the system where this is already broken.)
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence. We like people
MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9605101847.AA28294>