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>