From owner-freebsd-stable@FreeBSD.ORG  Mon May 26 09:24:41 2003
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id DBA5137B401
	for <stable@freebsd.org>; Mon, 26 May 2003 09:24:41 -0700 (PDT)
Received: from albatross.mail.pas.earthlink.net
	(albatross.mail.pas.earthlink.net [207.217.120.120])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5BA9343F75
	for <stable@freebsd.org>; Mon, 26 May 2003 09:24:41 -0700 (PDT)
	(envelope-from mvh@ix.netcom.com)
Received: from lsanca1-ar6-4-62-202-071.lsanca1.elnk.dsl.genuity.net
	([4.62.202.71] helo=netcom1.netcom.com)
	by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 19KKm8-0003jU-00; Mon, 26 May 2003 09:24:40 -0700
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by netcom1.netcom.com (Postfix) with ESMTP
	id 3302A5312; Mon, 26 May 2003 09:24:40 -0700 (PDT)
From: Mike Harding <mvh@ix.netcom.com>
To: "Marc G. Fournier" <scrappy@hub.org>
In-Reply-To: <20030526130556.G56519@hub.org>
References: <20030521171941.364325314@netcom1.netcom.com>
	<1053929957.7831.2.camel@netcom1.netcom.com>
	<20030526123617.D56519@hub.org>
	<1053964809.7831.6.camel@netcom1.netcom.com>
	<20030526130556.G56519@hub.org>
Content-Type: text/plain
Organization: 
Message-Id: <1053966279.7831.20.camel@netcom1.netcom.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 26 May 2003 09:24:40 -0700
Content-Transfer-Encoding: 7bit
cc: stable@freebsd.org
Subject: Re: system slowdown - vnode related
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Production branch of FreeBSD source code
	<freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2003 16:24:42 -0000

On my sytem, with 512 meg of memory, I have the following (default)
vnode related values:

bash-2.05b$ sysctl -a | grep vnode
kern.maxvnodes: 36079
kern.minvnodes: 9019
vm.stats.vm.v_vnodein: 140817
vm.stats.vm.v_vnodeout: 0
vm.stats.vm.v_vnodepgsin: 543264
vm.stats.vm.v_vnodepgsout: 0
debug.sizeof.vnode: 168
debug.numvnodes: 33711
debug.wantfreevnodes: 25
debug.freevnodes: 5823

...is this really low?  Is this something that should go into
tuning(7)?  I searched on google and found basically nothing related to
adjust vnodes - although I am admittedly flogging the system - I have
leafnode+ running, a mirrored CVS tree, an experimental CVS tree,
mount_union'd /usr/ports in a jaile, and so on.  Damn those $1 a
gigabyte drives!

On Mon, 2003-05-26 at 09:12, Marc G. Fournier wrote:
> On Mon, 26 May 2003, Mike Harding wrote:
> 
> > Er - are any changes made to RELENG_4_8 that aren't made to RELENG_4?  I
> > thought it was the other way around - that 4_8 only got _some_ of the
> > changes to RELENG_4...
> 
> Ack, my fault ... sorry, wasn't thinking :(  RELENG_4 is correct ... I
> should have confirmed my settings before blathering on ...
> 
> One of the scripts I used extensively while debugging this ... a quite
> simple one .. was:
> 
> #!/bin/tcsh
> while ( 1 )
>   echo `sysctl debug.numvnodes` - `sysctl debug.freevnodes` - `sysctl debug.vnlru_nowhere` - `ps auxl | grep vnlru | grep -v grep | awk '{print $20}'`
>   sleep 10
> end
> 
> which outputs this:
> 
> debug.numvnodes: 463421 - debug.freevnodes: 220349 - debug.vnlru_nowhere: 3 - vlruwt
> 
> I have my maxvnodes set to 512k right now ... now, when the server "hung",
> the output would look something like (this would be with 'default' vnodes):
> 
> debug.numvnodes: 199252 - debug.freevnodes: 23 - debug.vnlru_nowhere: 12 - vlrup
> 
> with the critical bit being the vlruwt -> vlrup change ...
> 
> with unionfs, you are using two vnodes per file, instead of one in
> non-union mode, which is why I went to 512k vs the default of ~256k vnodes
> ... it doesn't *fix* the problem, it only reduces its occurance ...