Date: Mon, 3 Aug 2015 15:00:07 +0000 From: Matt Churchyard <matt.churchyard@userve.net> To: Alexander Leidinger <Alexander@Leidinger.net>, Quartz <quartz@sneakertech.com> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: RE: ZFS: Disabling ARC? Message-ID: <45e74b89dd754991a366a46aa5101822@SERVER.ad.usd-group.com> In-Reply-To: <20150801133635.00002ecc@Leidinger.net> References: <55BC14B7.9010009@sneakertech.com> <20150801133635.00002ecc@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>On Fri, 31 Jul 2015 20:37:11 -0400 >Quartz <quartz@sneakertech.com> wrote: > Can someone help clear up a few ZFS basics for me? >=20 > A few recent threads about ARC issues and memory-induced panics have=20 > made me realize I'm not 100% sure I understand ARC as well as I=20 > thought I did. >=20 > Say you have a ZFS file server that houses very large single files=20 > which are very infrequently accessed. For the sake of argument, let's=20 > say you're using ZFS on a home server for your family, and it holds=20 > exclusively a whole bunch of multi-gig bluray rips or whatever=20 > (nothing else). When someone wants to watch something, they copy the=20 > file to their desktop and watch it there. Although the family will=20 > watch several videos each day, any given file will only be accessed=20 > maybe once every couple months. (I know streaming would make more=20 > sense in real life, and that this example is kinda silly in general,=20 > but ignore that for now). >No matter if you stream or copy, it's the same operation, read once in a w= hile. > If I understand ARC correctly this would be a worst case scenario,=20 > right? Besides hogging ram, would ARC cause any problems here? Would=20 > disabling ARC and devoting the ram to other things be a wise idea? Is=20 > disabling ARC ever a wise idea? >You can tune how the ARC is used: ># zfs get all space/export/Movies | grep cache >space/export/Movies primarycache metadata local >space/export/Movies secondarycache none local >"primarycache" is the ARC in RAM, "secondarycache" is a cache device / L2A= RC (SSD). >"metadata" is directory listing, file sizes, access permissions and the li= ke. >So the above example means that metadata is allowed to go to the ARC in RA= M, and nothing of the real data in this dataset shall be cached >anywhere a= t all (neither in a cache device nor in RAM). >Bye, >Alexander. >-- >http://www.Leidinger.net Alexander@Leidinger.net: PGP 0xC773696B3BAC17DC >http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0xC773696B3BAC17DC I don't know if it's changed, but even changing ARC to metadata only used t= o cause massive performance issues when reading large files in small chunks= . Reading a 128k ZFS record in 4k chunks would cause ZFS to read the same 1= 28k record from disk 32 times. There's a forum thread about it here - https://forums.freebsd.org/threads/z= fs-primarycache-all-versus-metadata.45555/ Generally I've found ARC to be one of the most important parts of ZFS. Ther= e's no case I know of where it will actually adversely affect performance (= not that I've really looked). Its only downside is that it doesn't seem to = manage memory as well as it should, and so a lot of people (including me) h= ave resorted to limiting it. While it seems easy to "tune" using the primarycache option, it's rarely a = good idea except for very specific situations. If ARC isn't getting many hits (I use sysutils/zfs-stats to view stats), an= d you really don't want it using up all your memory, just reduce arc_max. Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45e74b89dd754991a366a46aa5101822>