Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Apr 2010 22:02:39 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Petr Salinger <Petr.Salinger@seznam.cz>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: leak of the vnodes
Message-ID:  <20100402190239.GL2415@deviant.kiev.zoral.com.ua>
In-Reply-To: <Pine.LNX.4.62.1004021934550.15800@sci.felk.cvut.cz>
References:  <Pine.LNX.4.62.1004021934550.15800@sci.felk.cvut.cz>

next in thread | previous in thread | raw e-mail | index | archive | help

--LQhvuUkKKd6r3A8m
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 02, 2010 at 07:45:03PM +0200, Petr Salinger wrote:
> Hi,
>=20
> I have the same problem as in
> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-August/029227.html
>=20
> During "make check" of gcc-4.3 the vfs.numvnodes goes up,
> after reaching default limit 100000 the machine is stuck.
>=20
> 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
>=20
> It is not on plain FreeBSD, but the GNU/kFreeBSD
> changes to the kernel are minimal.
>=20
> The KTR trace of KTR_VFS from 8-stable is at
> http://asdfasdf.debian.net/~salinger/ktr.gz
>=20
> 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=3D1.

--LQhvuUkKKd6r3A8m
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAku2P04ACgkQC3+MBN1Mb4jY5wCgz2OVZX3eL7db9OJo4aP7WWhY
qEIAnA0gYOGJ1el2UNPEfM4A+1sMVizM
=aGyN
-----END PGP SIGNATURE-----

--LQhvuUkKKd6r3A8m--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100402190239.GL2415>