From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 18:17:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B532716A4CE; Sun, 18 Jul 2004 18:17:18 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C20843D45; Sun, 18 Jul 2004 18:17:18 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i6IIHHbi073446; Sun, 18 Jul 2004 14:17:17 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i6IIHG41073443; Sun, 18 Jul 2004 14:17:16 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 18 Jul 2004 14:17:16 -0400 (EDT) From: Andre Guibert de Bruet To: Daniel Lang In-Reply-To: <20040715193217.GC7804@atrbg11.informatik.tu-muenchen.de> Message-ID: <20040718135510.R24726@alpha.siliconlandmark.com> References: <20040715183415.GA7804@atrbg11.informatik.tu-muenchen.de> <20040715185801.GB7804@atrbg11.informatik.tu-muenchen.de> <20040715193217.GC7804@atrbg11.informatik.tu-muenchen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: Scott Long cc: current@freebsd.org Subject: Re: tuning hints for PAE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2004 18:17:18 -0000 On Thu, 15 Jul 2004, Daniel Lang wrote: > My values are the following (with adjusted maxvnodes): > [..] > kern.maxvnodes: 64000 > vnodes 35 7K 7K 166 16,32,64,128,256 > kern.minvnodes: 52958 > vm.stats.vm.v_vnodein: 568488 > vm.stats.vm.v_vnodeout: 1 > vm.stats.vm.v_vnodepgsin: 1384470 > vm.stats.vm.v_vnodepgsout: 1 > vfs.numvnodes: 190867 > vfs.wantfreevnodes: 25 > vfs.freevnodes: 135112 > debug.sizeof.vnode: 264 > [..] > > So the actual consumed memory (7k ?) appears neglectible. > However, kern.minvnodes has nearly reached the now upper limit, > so maybe trimming maxvnodes to 64000 was maybe too small, > and the saved space appears not worth the effort? > > I will bump it up a bit more... > > What about the 35 vnodes "In Use" (reported by kern.malloc) but > vfs.numvnodes: 190867, I am not sure how to interpret these > values.... > > As far as I understand it, a vnode is a kernel data-structure > referring to a file-like entity (file, directory, socket, pipe, etc). > So there are obviously much more in use than 35. 190867 appears > too much, for ~ 400 active processes. Even if there are many > filedescriptors open by each process, it is probably much less than 500 > per process. But maybe if these include all cached vnodes, so > all vnodes which have been in use in the past, it could fit. > > Sorry for being not too educated about this really basic > UNIX concept. :-} Daniel, If you are running a lot of dynamically-linked programs, an fd is allocated for every library that is imported. If you really want to find out what's going on where as far as fds on your system, lsof(8) from ports is your friend. Vnodes, are kernel-land structures that can reference any file or directory. Your vnode use count is always going to be greater than the number of open fds on your system. The two are somewhat related because you're guaranteed to have a vnode allocated for every file that is opened and for each process' current working directory (In the case of multiple programs accessing the same file or directory, the kernel increments the given vnode's reference count). The kernel keeps a vnode cache in order to limit the number of expensive lookups that would otherwise have to be performed while heavy I/O is under way. The namei(9) and vnode(9) manpages contain a wealth of information on the matter. I hope this helps. :) Regards, Andy > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/ >