From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 2 19:41:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354581065670 for ; Fri, 2 Apr 2010 19:41:03 +0000 (UTC) (envelope-from Petr.Salinger@seznam.cz) Received: from relay.felk.cvut.cz (relay.felk.cvut.cz [147.32.80.7]) by mx1.freebsd.org (Postfix) with ESMTP id B712B8FC18 for ; Fri, 2 Apr 2010 19:41:01 +0000 (UTC) Received: from sci.felk.cvut.cz (sci.felk.cvut.cz [147.32.83.100]) by relay.felk.cvut.cz (8.14.3/8.14.3) with ESMTP id o32Jeodu077554; Fri, 2 Apr 2010 21:40:50 +0200 (CEST) (envelope-from Petr.Salinger@seznam.cz) Date: Fri, 2 Apr 2010 23:46:41 +0200 (CEST) From: Petr Salinger X-X-Sender: salinger@sci.felk.cvut.cz To: Kostik Belousov In-Reply-To: <20100402190239.GL2415@deviant.kiev.zoral.com.ua> Message-ID: References: <20100402190239.GL2415@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-FELK-MailScanner-Information: X-MailScanner-ID: o32Jeodu077554 X-FELK-MailScanner: Found to be clean X-FELK-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.121, required 5, BAYES_00 -1.90, SPF_NEUTRAL 0.78) X-FELK-MailScanner-From: petr.salinger@seznam.cz X-FELK-MailScanner-To: freebsd-hackers@freebsd.org, kostikbel@gmail.com X-FELK-MailScanner-Watermark: 1270842051.90385@VjKjYZo3rAsK6y8giYjgCg X-Spam-Status: No X-Mailman-Approved-At: Fri, 02 Apr 2010 20:32:32 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: leak of the vnodes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 19:41:03 -0000 > 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