From owner-freebsd-fs@FreeBSD.ORG Tue Apr 10 02:04:56 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30FFA16A400; Tue, 10 Apr 2007 02:04:56 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 15AE013C45B; Tue, 10 Apr 2007 02:04:56 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id D2C0311555; Mon, 9 Apr 2007 21:04:55 -0500 (CDT) Date: Mon, 9 Apr 2007 21:04:55 -0500 From: Craig Boston To: Kris Kennaway Message-ID: <20070410020455.GA73825@nowhere> References: <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> <20070410014233.GD8189@nowhere> <20070410015523.GA39181@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070410015523.GA39181@xor.obsecurity.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: ZFS committed to the FreeBSD base. 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: Tue, 10 Apr 2007 02:04:56 -0000 On Mon, Apr 09, 2007 at 09:55:23PM -0400, Kris Kennaway wrote: > That is a lifetime count of the # of operations, not the current > number allocated ("InUse"). Yes, perhaps I should have said "sheer number of allocations & deallocations". I was just surprised that it seems to grab and release memory much more often than anything else tracked by vmstat. > It does look like there is something else using a significant amount > of memory apart from arc, but arc might at least be the major one due > to its extremely greedy default allocation policy. I wasn't going to post again until somebody suggested trying this, but I think the name cache can be ruled out. I reduced vfs.zfs.dnlc.ncsize from ~13000 to 4096 with no appreciable drop in total memory usage. It seems to be stable with vm.kmem_size at 256MB, but the wired count has come dangerously close a few times. Craig