From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 16:28:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C491065673 for ; Mon, 29 Mar 2010 16:28:04 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [66.92.166.102]) by mx1.freebsd.org (Postfix) with ESMTP id 84FAE8FC0A for ; Mon, 29 Mar 2010 16:28:04 +0000 (UTC) Received: from [192.168.1.116] (portal.theptrgroup.com [71.178.251.28]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id o2TGRT1f023065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Mar 2010 16:27:34 GMT (envelope-from ben@wanderview.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Kelly In-Reply-To: <4BB0BC7C.3000801@barryp.org> Date: Mon, 29 Mar 2010 12:27:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6823460E-4878-4936-A827-75BBA97F2304@wanderview.com> References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <4BB0BC7C.3000801@barryp.org> To: Barry Pederson X-Mailer: Apple Mail (2.1077) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.67 on 10.76.20.1 Cc: jhell , FreeBSD Stable Subject: Re: ZFS Tuning - arc_summary.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:28:05 -0000 On Mar 29, 2010, at 10:43 AM, Barry Pederson wrote: > I've been using the arc_summary.pl script from here: >=20 > = http://jhell.googlecode.com/svn/base/head/scripts/zfs/arc_summary/arc_summ= ary.pl >=20 > and noticed some odd numbers, with the ARC Current Size being larger = than the Max Size, and the breakdown adding up to less than the current = size as shown below I believe the current size can be larger than the max if your working = data set is large enough. The ARC can't evict data that is still being = referenced. When I last looked (over a year ago) there was no mechanism = to provide back pressure from the ARC to the VM layer to request that = more nodes be released to help deal with this situation. I don't know if that really helps at all, but I just thought I would add = the data point from my previous debugging sessions with zfs. - Ben=