Date: Sat, 18 Apr 2009 17:25:17 -0400 From: Ben Kelly <ben@wanderview.com> To: =?ISO-8859-1?Q?Marius_N=FCnnerich?= <marius@nuenneri.ch> Cc: Alexander Leidinger <Alexander@leidinger.net>, ticso@cicely.de, fs@freebsd.org, current@freebsd.org Subject: Re: ZFS: unlimited arc cache growth? Message-ID: <6FBF637A-6D96-4117-85C5-F205989DCCC1@wanderview.com> In-Reply-To: <b649e5e0904170928p1568329bwb2f8a5f0f9b4f698@mail.gmail.com> References: <20090417145024.205173ighmwi4j0o@webmail.leidinger.net> <20090417141817.GR11551@cicely7.cicely.de> <b649e5e0904170928p1568329bwb2f8a5f0f9b4f698@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 17, 2009, at 12:28 PM, Marius N=FCnnerich wrote: > On Fri, Apr 17, 2009 at 16:18, Bernd Walter =20 > <ticso@cicely7.cicely.de> 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();=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6FBF637A-6D96-4117-85C5-F205989DCCC1>