kern/187594: [zfs] [patch] ZFS ARC behavior problem and fix
Andriy Gapon
avg at FreeBSD.org
Thu Mar 20 15:06:52 UTC 2014
on 20/03/2014 14:30 Karl Denninger said the following:
> The following reply was made to PR kern/187594; it has been noted by GNATS.
>
> From: Karl Denninger <karl at denninger.net>
> To: bug-followup at FreeBSD.org, karl at fs.denninger.net
> Cc:
> Subject: Re: kern/187594: [zfs] [patch] ZFS ARC behavior problem and fix
> Date: Thu, 20 Mar 2014 07:26:39 -0500
>
> This is a cryptographically signed message in MIME format.
>
> --------------ms010203060907010901070002
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: quoted-printable
>
> I am increasingly-convinced with increasing runtime now on both=20
> synthetic and real loads in production that the proper default value for =
>
> vfs.zfs.arc_freepages is vm.stats.vm.v_free_target less "just a bit." =20
> Five percent appears to be ok for most workloads with RAM configurations =
How about just changing vm_paging_needed() check to vm_paging_target() > 0
check? Could you please try to test this?
> ranging from 4GB to the 24GB area (configurations that I can easily test =
>
> under both synthetic and real environments.)
>
> Larger invasions of the free target increasingly risk provocation of the =
>
> behavior that prompted me to get involved in working this part of the=20
> code in the first place, including short-term (~5-10 second) "stalls"=20
> during which the system appears to be locked up, but is not.
>
> It appears that the key to avoiding that behavior is to not allow the=20
> ARC to continue to take RAM when a material invasion of that target=20
> space has occurred.
--
Andriy Gapon
More information about the freebsd-fs
mailing list