From owner-freebsd-performance@FreeBSD.ORG Sun Aug 7 20:24:48 2005 Return-Path: X-Original-To: freebsd-performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 779DE16A423 for ; Sun, 7 Aug 2005 20:24:48 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id C5E6343E30 for ; Sun, 7 Aug 2005 19:24:21 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 7 Aug 2005 20:24:20 +0100 (BST) Date: Sun, 7 Aug 2005 20:24:20 +0100 From: David Malone To: freebsd-performance@FreeBSD.org Message-ID: <20050807192420.GA83026@walton.maths.tcd.ie> References: <20050807185129.GA61807@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050807185129.GA61807@frontfree.net> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: Subject: Re: [RFC] Bumping ufs.dirhash_maxmem to a larger value? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2005 20:24:48 -0000 On Mon, Aug 08, 2005 at 02:51:29AM +0800, Xin LI wrote: > My proposal is to increase the default dirhash_maxmem value to at least > 32MB or 64MB. Any objections? I think autotuning the value on boot might be a good idea, providing that there's reasonable evidence that the existing value is too small. Maybe setting it to some fraction of the available ram might be a reasonable plan. I set it to 20MB on our NFS server which has 1GB of ram. That's more than enough enough to quickly clean up when a user accidently puts a million files in one directory. > Cons for this, discussed in -developer: > - dirhash does not implements automatical mechanism to reduce memory > usage in response to system memory pressure, and benefits mainly to > large directories, e.g. Maildirs. Note that it benefits *only* large directories. Making dirhash respond to demands on memory would be a good plan, certainly on -current where we can in principle get feedback from UMA about memory shortages. This would eliminate most of the disadvantages of increasing the limit. In fact, you might be able to remove the limit all together. David.