Date: Fri, 2 Apr 2010 23:46:41 +0200 (CEST) From: Petr Salinger <Petr.Salinger@seznam.cz> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: leak of the vnodes Message-ID: <Pine.LNX.4.62.1004022337010.16354@sci.felk.cvut.cz> In-Reply-To: <20100402190239.GL2415@deviant.kiev.zoral.com.ua> References: <Pine.LNX.4.62.1004021934550.15800@sci.felk.cvut.cz> <20100402190239.GL2415@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. The increase helps, the system become responsive. In fact I previously suspected scheduler, but change to 4BSD, UP, nopreemption didn't helped. The build directory of gcc-4.3 is in a separated mount point. Even after the build is stopped and the mount point unmounted, the vfs.numvnodes is still to high. The temporary files (*.s) are in /tmp, but they have been deleted, so my expectation is that vfs.numvnodes should lower significantly. > 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. I will test this. Petr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.62.1004022337010.16354>