ZFS not caching right?

[Brandon Weisz]

On Thu, 2007-09-13 at 22:25 +0100, Joao Barros wrote:
> On 9/10/07, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:
> > On Thu, Sep 06, 2007 at 08:48:53PM +0200, Ulrich Spoerlein wrote:
> > > Hi, it's me again with another stupid question,
> > >
> > > ever since I switched my /usr and /home to ZFS, the system has become
> > > _very_ unresponsive under load. This is not because of CPU load, but I/O
> > > load.
> >
> > Can you try recent HEAD? I committed a change that allows ZFS cache
> > (ARC) to use more memory. This should be safe after dfr@'s vnode leak
> > fix and should also help performance.
> >
> > --
> > Pawel Jakub Dawidek                       http://www.wheel.pl
> > pjd at FreeBSD.org                           http://www.FreeBSD.org
> > FreeBSD committer                         Am I Evil? Yes, I Am!
> >
> >
> 
> This happened 1 day after compiling new sources:
> panic: kmem_malloc(90112): kmem_map too small: 329805824 total allocated
> when writing through NFS.
> On FreeBSD xeon.bsdtech.org 7.0-CURRENT FreeBSD 7.0-CURRENT #8: Tue
> Sep 11 00:08:39 WEST 2007
> root at xeon.bsdtech.org:/usr/obj/usr/src/sys/GENERIC  i386
> Machine has 1GB of ram and:
> vfs.zfs.arc_min: 16777216
> vfs.zfs.arc_max: 251658240
> vfs.zfs.mdcomp_disable: 0
> vfs.zfs.prefetch_disable: 1
> vfs.zfs.zio.taskq_threads: 0
> vfs.zfs.recover: 0
> vfs.zfs.vdev.cache.size: 10485760
> vfs.zfs.vdev.cache.max: 16384
> vfs.zfs.cache_flush_disable: 0
> vfs.zfs.zil_disable: 0
> vfs.zfs.debug: 0
> 
> I hadn't had any panics with sources from August 16 but before your
> recent changes vfs.zfs.arc_max was 167772160
> kern.maxvnodes is not set to 50000 as recomended ( on purpose ) and is
> currently at 52242 set by the system. Is 50000 still recomended after
> your changes?
> 

Just a "me too" -

I am also seeing "kmem_map too small" panics on a amd64 NFS server with
1 GB ram after the recent zfs changes.  setting
vm.kmem_size_max="402653184" seems to have stopped the panics, however
this was not needed previously.

Brandon