From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 21:13:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB5C4106566B for ; Fri, 17 Apr 2009 21:13:58 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9BE8FC17 for ; Fri, 17 Apr 2009 21:13:58 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n3HKxwIo072138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Apr 2009 15:59:59 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n3HKxw3j099656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Apr 2009 15:59:58 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n3HKxtlu099641; Fri, 17 Apr 2009 15:59:55 -0500 (CDT) (envelope-from dan) Date: Fri, 17 Apr 2009 15:59:55 -0500 From: Dan Nelson To: ticso@cicely.de Message-ID: <20090417205955.GK90152@dan.emsphone.com> References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090417141817.GR11551@cicely7.cicely.de> <20090417190551.GT11551@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090417190551.GT11551@cicely7.cicely.de> X-OS: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Fri, 17 Apr 2009 15:59:59 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Alexander Leidinger , Marius =?utf-8?Q?N=C3=BCnnerich?= , current@freebsd.org, fs@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 21:14:00 -0000 In the last episode (Apr 17), Bernd Walter said: > On Fri, Apr 17, 2009 at 06:28:29PM +0200, Marius Nünnerich wrote: > > On Fri, Apr 17, 2009 at 16:18, Bernd Walter wrote: > > > On Fri, Apr 17, 2009 at 02:50:24PM +0200, Alexander Leidinger wrote: > > >> I monitored (by hand) a while the sysctls > > >> kstat.zfs.misc.arcstats.size and kstat.zfs.misc.arcstats.hdr_size. > > >> Both grow way higher (at some point I've seen more than 500M) than > > >> what I have configured in vfs.zfs.arc_max (40M). > > > > > > My understanding about this is the following: vfs.zfs.arc_min/max are > > > not used as min max values. They are used as high/low watermarks. If > > > arc is more than max the arc a thread is triggered to reduce the arc > > > cache until min, but in the meantime other threads can still grow arc > > > so there is a race between them. > > > > Hmm, if this is true the ARC size should go down to arc_min once it did > > grow past arc_max and no new data is coming along but I do not observe > > such a thing here. It simply stays near but below arc_max here all the > > time. I have only /home on ZFS with moderate load. > > I had a few ideas why this could be, but scanning complete sys showed no > point at all where arc_min is used. There are formular to set this value, > but that's all I find. zfs_arc_{min,max} are just tunables. The real variables arc_c_{min,max} get autosized and then capped to {min,max} in uts/common/fs/zfs/arc.c:arc_init() . -- Dan Nelson dnelson@allantgroup.com