Subject: Re: mbuf leak (old)?
To: Jukka Marin <firstname.lastname@example.org>
From: Curt Sampson <email@example.com>
Date: 04/25/1997 14:01:42
On Fri, 25 Apr 1997, Jukka Marin wrote:
> 33/260 mapped pages in use
> 539 Kbytes allocated to network (15% in use)
> The amount of allocated memory seems to grow slowly. Is this some kind of
> special kernel memory which I will soon run out of?
I think I undersand this correctly, but look forward to corrections
from the real gurus out there.
There is an area in the kernel virtual memory map that initially
has no physical pages backing it, but serves as the malloc arena
for mbuf clusters. (An mbuf cluster is a 2K chunk of memory that
we attach to an mbuf when we have enough data in a packet to fill
more than two mbufs.)
So every time networking code requests another mbuf cluster, it
gets one out of that malloc arena. The system either hands the
networking code a mapped one that has been used before and returned,
or, if there are no free mapped ones, maps some more physical memory
into that space and hands out the mbuf cluster.
So what you're seeing above is that the maximum demand for mbuf
clusters at any one time in the past has been 260 pages worth, and
currently there are 33 pages worth in use.
Your situation doesn't really look like anything to worry about;
these figures aren't outrageous. A moderately busy server (a 486)
looks like this:
1707 mbufs in use:
1388 mbufs allocated to data
317 mbufs allocated to packet headers
2 mbufs allocated to socket names and addresses
342/592 mapped pages in use
1397 Kbytes allocated to network (64% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
Curt Sampson firstname.lastname@example.org Info at http://www.portal.ca/
Internet Portal Services, Inc. Through infinite myst, software reverberates
Vancouver, BC (604) 257-9400 In code possess'd of invisible folly.