From owner-freebsd-fs@FreeBSD.ORG Fri Oct 21 15:38:47 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AFC5106566B; Fri, 21 Oct 2011 15:38:47 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0D88FC18; Fri, 21 Oct 2011 15:38:46 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 36DEF28424; Fri, 21 Oct 2011 17:38:45 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id DF63D28422; Fri, 21 Oct 2011 17:38:43 +0200 (CEST) Message-ID: <4EA19203.5050503@quip.cz> Date: Fri, 21 Oct 2011 17:38:43 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Ivan Voras References: <4E97FEDD.7060205@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: dirhash and dynamic memory allocation X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:38:47 -0000 Hi, I am back on this topic... Ivan Voras wrote: > On 14/10/2011 11:20, Miroslav Lachman wrote: >> Hi all, >> >> I tried some tuning of dirhash on our servers and after googlig a bit, I >> found an old GSoC project wiki page about Dynamic Memory Allocation for >> Dirhash: http://wiki.freebsd.org/DirhashDynamicMemory >> Is there any reason not to use it / not commit it to HEAD? > > AFAIK it's sort-of already present. In 8-stable and recent kernels you > can give huge amounts of memory to dirhash via vfs.ufs.dirhash_maxmem > (but except in really large edge cases I don't think you *need* more > than 32 MB), and the kernel will scale-down or free the memory if not > needed. > > In effect, vfs.ufs.dirhash_maxmem is the upper limit - the kernel will > use less and will free the allocated memory in low memory situations > (which I've tried and it works). So the current behavior is that on 7.3+ and 8.x we have smaller average dirhash buffer (by default) than it was initialy 10 years ago. Because it starts as 2MB fixed size and now we have 2MB max, which is lowered in low mem situations... and sometimes it is set to 0MB! I caught this 2 days ago: root@rip ~/# sysctl vfs.ufs vfs.ufs.dirhash_reclaimage: 5 vfs.ufs.dirhash_lowmemcount: 36953 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 0 vfs.ufs.dirhash_maxmem: 8388608 vfs.ufs.dirhash_minsize: 2560 I set maxmem to 8MB in sysctl.conf to increase performance and dirhash_mem 0 is really bad surprise! I am worrying about bad performance in situation where dirhash is emptied in situations, where server is already running at maximum performance (there is some memory hungry process and system can start swapping to disk + dirhash is efectively disabled) I found a PR kern/145246 http://www.freebsd.org/cgi/query-pr.cgi?pr=145246 Is it possible to add some dirhash_minmem limit to not clear all the dirhash memory? So I can set dirhash_minmem=2MB dirhash_maxmem=16MB and then dirhash_mem will be allways between these two limits? >> And second question - is there any negative impact with higher >> vfs.ufs.dirhash_maxmem? It stil defaults to 2MB (on FreeBSD 8.2) after > > Not that I know of. > >> 10 years, but I think we all are using bigger FS in these days with lot >> of files and directories and 2MB is not enough. > > AFAIK I've changed it to autotune so it's configured to approximately 4 > MB on a 4 GB machine (and scales up) in 9. I didn't tried 9 yet. Does it mean dirhash_maxmem is initially set to approximately 1% of physical RAM and then it can be set higher by sysctl as in older versions? Miroslav Lachman