Date: Mon, 15 Feb 2010 13:00:20 -0500 (EST) From: "Peter C. Lai" <peter@simons-rock.edu> To: "Artem Belevich" <fbsdlist@src.cx> Cc: Alexander Leidinger <alexander@leidinger.net>, freebsd-stable@freebsd.org, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: hardware for home use large storage Message-ID: <1140.69.37.94.221.1266256820.squirrel@lock.simons-rock.edu> In-Reply-To: <ed91d4a81002150854w421b054oc81eb88ae767f5b4@mail.gmail.com> References: <cf9b1ee01002150049o43fced71ucb5776a0a1eaf4cf@mail.gmail.com> <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <ed91d4a81002150854w421b054oc81eb88ae767f5b4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> * vm.kmem_size >>> * vm.kmem_size_max >> >> I tried kmem_size_max on -current (this year), and I got a panic during >> use, >> I changed kmem_size to the same value I have for _max and it didn't >> panic >> anymore. It looks (from mails on the lists) that _max is supposed to >> give a >> max value for auto-enhancement, but at least it was not working with ZFS >> last month (and I doubt it works now). > > It used to be that vm.kmem_size_max needed to be bumped to allow for > larger vm.kmem_size. It's no longer needed on amd64. Not sure about > i386. > > vm.kmem_size still needs tuning, though. While vm.kmem_size_max is no > longer a limit, there are other checks in place that result in default > vm.kmem_size being a bit on the conservative side for ZFS. > >>> Then, when it comes to debugging problems as a result of tuning >>> improperly (or entire lack of), the following counters (not tunables) >>> are thrown into the mix as "things people should look at": >>> >>> kstat.zfs.misc.arcstats.c >>> kstat.zfs.misc.arcstats.c_min >>> kstat.zfs.misc.arcstats.c_max >> >> c_max is vfs.zfs.arc_max, c_min is vfs.zfs.arc_min. >> >>> kstat.zfs.misc.arcstats.evict_skip >>> kstat.zfs.misc.arcstats.memory_throttle_count >>> kstat.zfs.misc.arcstats.size >> >> I'm not very sure about size and c... both represent some kind of >> current >> size, but they are not the same. > > arcstats.c -- adaptive ARC target size. I.e. that's what ZFS thinks it > can grow ARC to. It's dynamically adjusted based on when/how ZFS is > back-pressured for memory. > arcstats.size -- current ARC size > arcstats.p -- portion of arcstats.c that's used by "Most Recently > Used" items. What's left of arcstats.c is used by "Most Frequently > Used" items. > > --Artem > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > How much ram are you running with? In a latest test with 8.0-R on i386 with 2GB of ram, an install to a ZFS root *will* panic the kernel with kmem_size too small with default settings. Even dropping down to Cy Schubert's uber-small config will panic the kernel (vm.kmem_size_max = 330M, vfs.zfs.arc_size = 40M, vfs.zfs.vdev.cache_size = 5M); the system is currently stable using DIST kernel, vm.kmem_size/max = 512M, arc_size = 40M and vdev.cache_size = 5M. -- Peter C. Lai ITS Systems Administrator Bard College at Simon's Rock 84 Alford Rd. Great Barrington, MA 01230 (413) 528-7428 peter at simons-rock.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1140.69.37.94.221.1266256820.squirrel>