From owner-freebsd-fs@FreeBSD.ORG Tue Jul 29 00:42:04 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 E9BDB1065678; Tue, 29 Jul 2008 00:42:04 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) Received: from outbound.icp-qv1-irony-out3.iinet.net.au (outbound.icp-qv1-irony-out3.iinet.net.au [203.59.1.148]) by mx1.freebsd.org (Postfix) with ESMTP id EDEA18FC0A; Tue, 29 Jul 2008 00:42:03 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAAN8BjkjLzq3r/2dsb2JhbAAIixWkTA X-IronPort-AV: E=Sophos;i="4.31,269,1215360000"; d="scan'208";a="295190522" Received: from unknown (HELO [10.24.1.1]) ([203.206.173.235]) by outbound.icp-qv1-irony-out3.iinet.net.au with ESMTP; 29 Jul 2008 08:31:56 +0800 Message-ID: <488E647C.7@mawer.org> Date: Tue, 29 Jul 2008 10:29:48 +1000 From: Antony Mawer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ivan Voras References: <20080727125413.GG1345@garage.freebsd.pl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org 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: Tue, 29 Jul 2008 00:42:05 -0000 Ivan Voras wrote: > Pawel Jakub Dawidek wrote: >> Hi. >> >> http://people.freebsd.org/~pjd/patches/zfs_20080727.patch.bz2 >> >> The patch above contains the most recent ZFS version that could be found >> in OpenSolaris as of today. Apart for large amount of new functionality, >> I belive there are many stability (and also performance) improvements >> compared to the version from the base system. >> >> Check out OpenSolaris website to find out the differences between base >> system version and patch version. >> >> Please test, test, test. If I get enough positive feedback, I may be >> able to squeeze it into 7.1-RELEASE, but this might be hard. > > I currently don't have high-end (4 CPU+) AMD64 machines to test, but > with 1 CPU i386 virtual machine in VMWare, with 1 GB of memory, > kmem_size=kmem_size_max=512M and no other tuning, with latest zpool > format (11) it took about 15 minutes to get a "kmem_map too small" panic > on a mixed load (buildkernel + blogbench + bonnie++). > > I've then tried the same load on the "real" hardware, 2 CPU, 2 GB > memory, kmem_size=kmem_size_max=512M, and no other tuning, with the > older zpool format (6) i get the same panic, though it takes about twice > as long to happen. Have you tried tuning arc_max and/or monitoring vmstat -m to see what is happening? What does arc_max get auto-tuned to at the moment (ie. without manually specifying)? One of the things I recall reading that arc_max is more like a guide, as some ZFS threads can exceed the max whilst other thread(s) go around cleaning up and freeing memory once the limit is hit. Maybe some better smarts are needed in auto-tuning arc_max so that it leaves more of a buffer zone than it does at the moment...? --Antony