leak of the vnodes

[Kostik Belousov]

On Fri, Apr 02, 2010 at 07:45:03PM +0200, Petr Salinger wrote:
> Hi,
> 
> I have the same problem as in
> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-August/029227.html
> 
> During "make check" of gcc-4.3 the vfs.numvnodes goes up,
> after reaching default limit 100000 the machine is stuck.
> 
> kern.maxvnodes: 100000
> kern.sigqueue.alloc_fail: 0
> kern.sigqueue.overflow: 371
> kern.sigqueue.preallocate: 1024
> kern.sigqueue.max_pending_per_proc: 128
> kern.minvnodes: 25000
> vfs.freevnodes: 22
> vfs.wantfreevnodes: 25000
> vfs.numvnodes: 100005
> debug.vnlru_nowhere: 811
> 
> It is not on plain FreeBSD, but the GNU/kFreeBSD
> changes to the kernel are minimal.
> 
> The KTR trace of KTR_VFS from 8-stable is at
> http://asdfasdf.debian.net/~salinger/ktr.gz
> 
> Thanks for any hints.

Is machine completely stuck, or is it makes small steps once in a second ?
You could look at the "ps alx" output, or ps output from ddb. Look for
the processes in the "vnlru" state.

If my suspection is true, you have such processes. The typical cause is
the large directory hierarchy. vnlru daemon does not reclaim the free
vnodes that are sources of namecache records.

You can either increase kern.maxvnodes, the default value is very
conservative on amd64, where a lot of KVA is available. On the other
hand, increase of the value on i386 could easily cause KVA exhaustion.

Another possible workaround, if you do not need path resolutions in /proc
or lsof(1), is to set sysctl vfs.vlru_allow_cache_src=1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100402/64262d29/attachment.pgp