Subject: Re: increasing NMBCLUSTERS
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Chuck Silvers <chuq@chuq.com>
List: tech-net
Date: 09/29/2005 09:15:18
On Thu, Sep 29, 2005 at 05:51:30PM +0200, Manuel Bouyer wrote:
> On Thu, Sep 29, 2005 at 07:59:25AM -0700, Chuck Silvers wrote:
> > On Thu, Sep 29, 2005 at 04:45:42PM +0200, Manuel Bouyer wrote:
> > > On Thu, Sep 29, 2005 at 07:25:44AM -0700, Chuck Silvers wrote:
> > > > I was just looking at a similar problem on john klos's cobalt box last night:
> > > > 
> > > > Name        Size Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle
> > > > mbpl         256  2030774    0  2013827  2924  1691  1233  1321     1   inf    0
> > > > mclpl       2048   429969 5987311 413585 40542 32346 8196  8196     4  8192    4
> > > > 
> > > > # netstat -m
> > > > 16540 mbufs in use:
> > > >         16538 mbufs allocated to data
> > > >         2 mbufs allocated to packet headers
> > > > 6001641 calls to protocol drain routines
> > > 
> > > This time the number of mclpl used matches the number of mbufs:
> > > 429969 - 413585 = 16384 (this more or less matches the 16540 mbufs in use).
> > 
> > what about the non-cluster mbufs?  there are many of those too.
> 
> For each cluster, you need a non-cluster. A mclpl doesn't contain mbuf, only
> storage.

ah, ok.  shows how little I know about the network code.


> > that shows only one TCP connection in the dump, and it has nothing in
> > its send or receive queues.
> 
> So the mbufs are used somewhere else. At last in your case, the clusters are
> still attached to mbufs.

yea, but the machine was in this state for over 12 hours.
so it looks like we have two different leaks.

-Chuck