From owner-freebsd-stable@FreeBSD.ORG Mon Feb 15 18:00:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74130106566C for ; Mon, 15 Feb 2010 18:00:23 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7E88FC19 for ; Mon, 15 Feb 2010 18:00:22 +0000 (UTC) Received: from lock.simons-rock.edu (lock.simons-rock.edu [192.168.2.211]) by hedwig.simons-rock.edu (Postfix) with ESMTP id 5E0A72BB360; Mon, 15 Feb 2010 13:00:22 -0500 (EST) Received: from lock.simons-rock.edu (lock.simons-rock.edu [127.0.0.1]) by lock.simons-rock.edu (8.13.1/8.13.1) with ESMTP id o1FI0M9J000588; Mon, 15 Feb 2010 13:00:22 -0500 Received: (from apache@localhost) by lock.simons-rock.edu (8.13.1/8.13.1/Submit) id o1FI0KbQ000587; Mon, 15 Feb 2010 13:00:20 -0500 X-Authentication-Warning: lock.simons-rock.edu: apache set sender to peter@simons-rock.edu using -f Received: from 69.37.94.221 (SquirrelMail authenticated user peter) by lock.simons-rock.edu with HTTP; Mon, 15 Feb 2010 13:00:20 -0500 (EST) Message-ID: <1140.69.37.94.221.1266256820.squirrel@lock.simons-rock.edu> In-Reply-To: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> Date: Mon, 15 Feb 2010 13:00:20 -0500 (EST) From: "Peter C. Lai" To: "Artem Belevich" User-Agent: SquirrelMail/1.4.8-5.el4_8.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Alexander Leidinger , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: hardware for home use large storage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:00:23 -0000 >>> * 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