From owner-freebsd-current@FreeBSD.ORG Sat Apr 18 21:25:22 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 A30AD106566C; Sat, 18 Apr 2009 21:25:22 +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 2C6338FC25; Sat, 18 Apr 2009 21:25:21 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from harkness.in.wanderview.com (harkness.in.wanderview.com [10.76.10.150]) (authenticated bits=0) by mail.wanderview.com (8.14.3/8.14.3) with ESMTP id n3ILPHve003379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Apr 2009 21:25:18 GMT (envelope-from ben@wanderview.com) Message-Id: <6FBF637A-6D96-4117-85C5-F205989DCCC1@wanderview.com> From: Ben Kelly To: =?ISO-8859-1?Q?Marius_N=FCnnerich?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 18 Apr 2009 17:25:17 -0400 References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090417141817.GR11551@cicely7.cicely.de> X-Mailer: Apple Mail (2.930.3) X-Spam-Score: -1.44 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.64 on 10.76.20.1 Cc: Alexander Leidinger , ticso@cicely.de, fs@freebsd.org, current@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: Sat, 18 Apr 2009 21:25:22 -0000 On Apr 17, 2009, at 12:28 PM, Marius N=FCnnerich wrote: > On Fri, Apr 17, 2009 at 16:18, Bernd Walter =20 > wrote: >> On Fri, Apr 17, 2009 at 02:50:24PM +0200, Alexander Leidinger wrote: >>> Hi, >>> >>> to fs@, please CC me, as I'm not subscribed. >>> >>> I monitored (by hand) a while the sysctls =20 >>> 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. It appears arc_reclaim_thread only shrinks from arc_max when the =20 system vm_lowmem event is fired or more than 75% of max kmem is in use =20= by the system. If you want to make it try to shrink the arc all the time you could =20 try the patch below. This worked to reduce arc_c on my system, but it =20= was unable to reduce arc_size to match due to an apparent mutex miss. =20= I'm still trying to track that down. Hope that helps. - Ben Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c =20 (revision 205) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c =20 (working copy) @@ -1963,7 +1963,7 @@ if (needfree || (2 * arc_c < arc_size + arc_mru_ghost->arcs_size + arc_mfu_ghost-=20 >arcs_size)) - arc_adjust(); + arc_shrink(); if (arc_eviction_list !=3D NULL) arc_do_user_evicts();=