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