From owner-freebsd-fs@FreeBSD.ORG Mon Jul 28 21:28:23 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 428011065674; Mon, 28 Jul 2008 21:28:23 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) Received: from outbound.icp-qv1-irony-out1.iinet.net.au (outbound.icp-qv1-irony-out1.iinet.net.au [203.59.1.108]) by mx1.freebsd.org (Postfix) with ESMTP id 732618FC16; Mon, 28 Jul 2008 21:28:22 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAAKTUjUh8qnCp/2dsb2JhbAAIixSlPQ X-IronPort-AV: E=Sophos;i="4.31,267,1215360000"; d="scan'208";a="362904582" Received: from unknown (HELO [10.4.0.197]) ([124.170.112.169]) by outbound.icp-qv1-irony-out1.iinet.net.au with ESMTP; 29 Jul 2008 05:18:07 +0800 Message-ID: <488E378B.40406@mawer.org> Date: Tue, 29 Jul 2008 07:18:03 +1000 From: Antony Mawer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: OutBackdingo References: <20080727125413.GG1345@garage.freebsd.pl> <200807272034.01290.max@love2party.net> <20080728083303.GD2953@garage.freebsd.pl> <200807281454.36892.max@love2party.net> <20080728125711.GH2953@garage.freebsd.pl> <1217250051.6657.0.camel@dingo-laptop> In-Reply-To: <1217250051.6657.0.camel@dingo-laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Max Laier , freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: ZFS patches. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 21:28:23 -0000 I have a single-disk i386 system with 1GB RAM, 512MB kmem, which now appears to be perfectly stable... It's a Via Epia system (C3 1GHz) so it's not exactly high-end hardware. This is running 7-STABLE from ~16 May 2008 (without the most recent patches applied), and the following configuration in /boot/loader.conf: # Root on ZFS zfs_load="YES" vfs.root.mountfrom="zfs:tank" # Tune kernel KVA space vm.kmem_size="512M" vm.kmem_size_max="512M" # Tune ZFS arc and vdev cache sizes vfs.zfs.arc_min="16M" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M" # Disable prefetch to improve performance vfs.zfs.prefetch_disable="1" Some of these tunings may be superfluous, but until I added them recently the box never lasted more than 2-3 days. It's now been up for 3 weeks without a panic. Kernel memory usage is comfortable: # kmem TEXT=6285036, 5.99388 MB DATA=93330432, 89.0068 MB TOTAL=99615468, 95.0007 MB The kmem script is the one posted on the FreeBSD wiki. The highest I have seen it climb is ~102mb, which to me suggests I can afford to tune the vfs.zfs.arc_max value higher (I started out with a conservatively low value and planned to tune and tweak from there based on observing kernel memory usage). --Antony OutBackdingo wrote: > So are we saying that i386 with a default kmem of 512MB has gotten > psuedo stable with some load? > > On Mon, 2008-07-28 at 14:57 +0200, Pawel Jakub Dawidek wrote: >> On Mon, Jul 28, 2008 at 02:54:36PM +0200, Max Laier wrote: >>> On Monday 28 July 2008 10:33:03 Pawel Jakub Dawidek wrote: >>>> Yes, it should fix most if not all 'kmem_map too small' panics, at least >>>> from what I tried. Tunning kmem_size is still needed to get better >>>> performance. >>> With the i386 default settings it was not too hard to get the attached panic. >>> Some cpdup and rm cycles of src and ports to a single disk zfs pool. With >>> 512M I haven't been able to kill it, yet. >> I was probably too optimistic. The default kmem_size is probably just >> too low. I'm quite sure it would be too low even for Solaris.