> On Fri, Aug 27, 2004 at 02:01:15PM +0100, Richard Earnshaw wrote:
> > On Fri, 2004-08-27 at 13:24, Geoff Wing wrote:
> > I have a machine with 64M of ram.  The kernel 'processes' (as shown in
> > top) used to take about 4M of that, maybe less until late last year. 
> > These days top shows the kernel hogging 18M of ram at present.  It never
> > drops, even when the machine starts thrashing.
> 
> 
> the big memory users in your data are:
> 
> > Memory statistics by type                           Type  Kern
> >          Type  InUse MemUse HighUse  Limit Requests Limit Limit Size(s)
> >       UVM amap  1348   194K   1835K  4301K580397389    0     0  16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,262144,524288
> >           ttys   566   368K    368K  4301K      566    0     0  128,1024
> 
> neither of these is fs-related, and neither seems excessive.
> 
> 
> > Memory resource pool statistics
> > Name        Size Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle
> > pvepl         16 2372304597  0 2372295804  97    32    65    84     3   inf    0
> > l2ptppl     1024    50092    0    49895  3300  3239    61   100     4   inf    0
> > ffsinopl     176 90990308    0 90982870  6064  5739   325   335     0   inf    0
> > dino1pl      128 90990308    0 90982870  4363  4122   241   249     0   inf    0
> > sigapl      2052 18440743    0 18440706  9098  9041    57    64     0   inf   20
> > ncachepl      84 89535830    0 89528971  3251  3101   150   161     0   inf    6
> > vnodepl      164  4820406    0  4812947  1667  1355   312   322     0   inf    0
> 
> the maximum number of vnodes the system will allocate is controlled by
> the sysctl node "kern.maxvnodes".  the management of memory used for
> vnodes and the like hasn't changed in a long time.  even if all of the
> memory used for these were freed, it would only return about 4MB to the
> system.   this doesn't seem to be the cause of the jump in memory usage
> that you've seen.
> 
> 
> and I'll include all of the pools for cached fs metadata:
> 
> > bufpl        120 48360022    0 48356406  7803  7693   110   123     0   inf    0
> > buf1k       1024  2099845    0  2097186  4417  4373    44    49     1   inf    0
> > buf2k       2048   325376    0   325261  2819  2815     4    26     1   inf    0
> > buf4k       4096   109667    0   109636  2538  2535     3    10     1   inf    0
> > buf8k       8192  1814843    0  1814033 36652 36523   129   232     1   inf    1
> 
> this is a very modest memory usage, only 1.1 MB.
> 
> 
> > In use 14733K, total allocated 17724K; utilization 83.1%
> 
> if I add up the "Npage" column, I only get 1731 pages, which is 6924KB
> (I'm assuming this is a pc).  where's the other 10MB hiding?

My PC at home (on which I'm not worried about the performance since it has
1GB of mem and to some extent can afford to use a fair amount for caching
things) shows similar discrepencies.  Here's the top few pool uses (sorted
by npages)

Name        Size Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg 
Maxpg Idle
buf1k       1024  1805840    0  1795974 10327  9788   539   909     1     
1    0
buf8k       8192  1070370    0  1063979 29391 28210  1181  2343     1     
1    0
ncachepl      84 74596492    0 74531051  2852  1112  1740  1819     0   
inf    0
bufpl        120 65893528    0 65877031 19463 17689  1774  2129     0   
inf   71
dino1pl      128 79606797    0 79541376  5081  2388  2693  2815     0   
inf    0
ffsinopl     176 79606797    0 79541376  7233  3605  3628  3795     0   
inf    3
vnodepl      164  7197316    0  7131873  4553   916  3637  3637     0   
inf    0
siginfo      128  3202157    0  3066636  4373     1  4372  4372     0   
inf    0

In use 118060K, total allocated 187416K; utilization 63.0%

(nothing else has more than 150 pages.)

Top reports the kernel as using about 205M of ram and sum(npage) * 4096 
comes to a mere (!) 84013056 bytes (~84M).

So somewhere the pools have 'lost' 100M of memory.

I'm somewhat concerned about that siginfo entry.  It's grabbed nearly 18M 
and hardly released anything...

R.