Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Jul 2008 10:29:48 +1000
From:      Antony Mawer <fbsd-fs@mawer.org>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        freebsd-fs@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: ZFS patches.
Message-ID:  <488E647C.7@mawer.org>
In-Reply-To: <g6ln6j$c7k$2@ger.gmane.org>
References:  <20080727125413.GG1345@garage.freebsd.pl> <g6ln6j$c7k$2@ger.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?488E647C.7>