From owner-freebsd-performance@FreeBSD.ORG Mon Aug 8 21:42:41 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 AC16616A41F for ; Mon, 8 Aug 2005 21:42:41 +0000 (GMT) (envelope-from tuliogs@pgt.mpt.gov.br) Received: from mail.pgt.mpt.gov.br (mail.pgt.mpt.gov.br [200.157.62.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE95143D49 for ; Mon, 8 Aug 2005 21:42:37 +0000 (GMT) (envelope-from tuliogs@pgt.mpt.gov.br) Received: from [10.0.0.136] (516e.pgt.mpt.gov.br [10.0.0.136]) by mail.pgt.mpt.gov.br (8.13.1/8.13.1) with ESMTP id j78Lgaj3033830 for ; Mon, 8 Aug 2005 18:42:36 -0300 (BRST) (envelope-from tuliogs@pgt.mpt.gov.br) Message-ID: <42F7D241.7060201@pgt.mpt.gov.br> Date: Mon, 08 Aug 2005 18:44:33 -0300 From: =?ISO-8859-1?Q?Tulio_Guimar=E3es_da_Silva?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-performance@freebsd.org Content-Type: multipart/mixed; boundary="------------010806040704080203020408" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [Fwd: 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: Mon, 08 Aug 2005 21:42:41 -0000 This is a multi-part message in MIME format. --------------010806040704080203020408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dumb me, forgot do redirect to the list. Sorry for that. Tulio G. Silva -------- Original Message -------- Subject: Re: [RFC] Bumping ufs.dirhash_maxmem to a larger value? Date: Mon, 08 Aug 2005 11:08:49 -0300 From: Tulio Guimarães da Silva To: Xin LI References: <20050807184707.GA61714@frontfree.net> <42F659AE.80905@mac.com> <20050807190533.GA61954@frontfree.net> I´m suggesting this without any clue of the amount of work required, but it´s a suggestion, anyway: maybe it could be dinamically calculated based on the growth of dirhash usage AND available RAM... I guess 10% is a reasonable *max* value, but this could also be disabled with a sysctl or compile time variable, à lá MAX_USERS. Say, if not set, or set to zero, then it´ll be dynamically calculated. For an initial value, maybe 2% is enough (the same 2MB for a 128MB machine). Since customized kernels are very frequent, this should not be an issue. Of course, the ideal "max percentage" could be obtained from beta-testing, since it should be by default set for a generic setup. But, again, I´m just guessing. ;) Tulio G. Silva Xin LI wrote: >On Sun, Aug 07, 2005 at 02:57:50PM -0400, Chuck Swiger wrote: >[snip] > > >>On the other hand, I've got several firewall boxes with only 128MB, and >>it's not reasonable to simply dedicate up to 64MB (half!) to dirhash >>without paying more attention to the amount of physical memory that is >>actually available. >> >> > >Forgot to mention that dirhash_maxmem is the upper limit, not the exact >amount that dirhash must use. If your firewall does not host zillion >of large directories then a bigger default dirhash_maxmem would >essentially a big no-op :-) > > > >>How big should dirhash_maxmem be? 5-10% of available RAM, perhaps? >> >> > >Actually this depends on how many large directories that you actively >access, not only the available RAM. If you access only a little of >small directories, e.g. hosting a database, then dirhash won't help >much. But with a lot of large directories having 1000+ files in most >of them, then raising the dirhash_maxmem will be a great help for >performance. > >I think it would be great if we can implement a automatical "suggested >value" of dirhash during bootstrap stage, though, which can be overridden >through sysctl.conf or subsequent sysctl. > >Cheers, > > --------------010806040704080203020408--