Subject: Re: Big NMBCLUSTERS on a busy Firewall
To: None <port-i386@netbsd.org>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: port-i386
Date: 09/20/2001 15:15:33
On Thu, Sep 20, 2001 at 08:31:36AM +0200, Christoph Kaegi wrote:
> On 2001.09.19 23:03, Manuel Bouyer wrote:
> >
> > And what does 'netstat -m' and 'vmstat -m' say ?
> >
>
> netstat -m:
>
> -------------------------------- 8< ---------------------------------
> 445 mbufs in use:
> 442 mbufs allocated to data
> 3 mbufs allocated to packet headers
> 430/2048 mapped pages in use
> 4648 Kbytes allocated to network (20% in use)
> 0 requests for memory denied
> 0 requests for memory delayed
> 109 calls to protocol drain routines
>
> -------------------------------- 8< ---------------------------------
Not that much mbufs in use rigth now, but maybe the machine isn't very
busy at this time.
>
> vmstat -m:
>
> -------------------------------- 8< ---------------------------------
> Kmem statistics are not being gathered by the kernel.
> Memory resource pool statistics
> Name Size Reqüsts Fail Releases Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle
> phpool 40 1180 0 0 12 0 12 12 0 inf 0
> pmappl 68 2817 0 2800 1 0 1 1 0 inf 0
> vmsppl 188 2817 0 2800 2 0 2 2 0 inf 1
> vmmpepl 64 55889 0 55615 6 0 6 6 0 inf 1
> uaoeltpl 84 0 0 0 0 0 0 0 0 inf 0
> aobjpl 52 0 0 0 0 0 0 0 0 inf 0
> amappl 40 27881 0 27743 2 0 2 2 0 inf 0
> mbpl 2561523837410 01523836888 138 0 138 138 1 inf 105
> mclpl 2048410545318 109410544831 1024 0 1024 1024 4 1024 780
> sockpl 164 7845 0 7840 1 0 1 1 0 inf 0
> ttypl 284 71 0 0 6 0 6 6 0 inf 0
> rndsample 528 742 0 733 2 0 2 2 0 inf 0
> procpl 404 2820 0 2800 3 0 3 3 0 inf 1
> pgrppl 24 441 0 427 1 0 1 1 0 inf 0
> pcredpl 24 2820 0 2800 1 0 1 1 0 inf 0
> plimitpl 156 29 0 25 1 0 1 1 0 inf 0
> rusgepl 72 2800 0 2800 1 0 1 1 0 inf 1
> filepl 48 45393 0 45353 1 0 1 1 0 inf 0
> cwdipl 12 2817 0 2800 1 0 1 1 0 inf 0
> fdescpl 124 2817 0 2800 1 0 1 1 0 inf 0
> vnodepl 208 8056 0 0 424 0 424 424 0 inf 0
> ncachepl 72 8056 0 0 144 0 144 144 0 inf 0
> ffsinopl 216 117245 0 109200 448 0 448 448 0 inf 0
> cd9660nopl 108 0 0 0 0 0 0 0 0 inf 0
> msdosnopl 100 0 0 0 0 0 0 0 0 inf 0
> wdcspl 48 46966 0 46966 1 0 1 1 0 inf 1
> scxspl 148 11 0 11 1 0 1 1 0 inf 1
> extent 20 160 0 143 1 0 1 1 0 inf 0
> bufpl 124 10 0 10 1 0 1 1 0 inf 1
> rtentpl 132 344096 0 344019 74 0 74 74 0 inf 68
> ipqepl 40 6 0 6 1 0 1 1 0 inf 1
> ipflowpl 72 0 0 0 0 0 0 0 0 inf 0
> inpcbpl 96 5079 0 5075 1 0 1 1 0 inf 0
> tcpcbpl 176 25 0 21 1 0 1 1 0 inf 0
> synpl 156 12 0 12 1 0 1 1 0 inf 1
> sigapl 840 2817 0 2800 7 0 7 7 0 inf 2
> swp buf 152 0 0 0 0 0 0 0 0 inf 0
> swp vnx 20 0 0 0 0 0 0 0 0 inf 0
> swp vnd 128 0 0 0 0 0 0 0 0 inf 0
>
> In use 5140K, total allocated 9236K; utilization 55.7%
> -------------------------------- 8< ---------------------------------
>
> Hm, very interesting! Where can I look up, these figures mean?
Each of these gives statistics on a kernel memory pool.
The one of interest is the mclpool:
Name Size Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle
mclpl 2048 410545318 109 410544831 1024 0 1024 1024 4 1024 780
(I adjusted the spaces to try to recover the initial numbers)
So 109 requests for memory to the mclpool failed (in 410545318).
There are 1024 pages allocated to the mclpool, so 4M or RAM.
You've request 32768 for nmbclusters, this should be 16384 pages (or 64M RAM)
(a mbclusters is 2k, so half a page on i386).
I'm not sure why the limit is 1024 pages here, does someone have an idea ?
Do we have a limit to the number of pages in a pool ?
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
--