Re: ZFS committed to the FreeBSD base.

On Mon, Apr 30, 2007 at 11:28:22PM +0200, Peter Schuller wrote:
> > Hi, just wanted to chime in that I'm experiencing the same panic with
> > a fresh -CURRENT.
> 
> I am also/still seeing the "kmem_map too small" panic on a tree cvsup:ed
> around April 27.
> 
> I can consistently trigger it by doing "rsync -a /usr/ports
> /somepool/somepath", with both /usr and /somepool being on ZFS
> (different pools). This is on a machine with 1 GB memory, with the kmem
> size being 320 MB as per default.
> 
> The kstat.zfs.misc.arcstats.size never jumps; the "solaris" memory usage
> never significantly jumps - stays between about 80 MB and 150 MB at all
> times. It does not even consistently increase in size within this range
> - it goes up and down.
> 
> In terms of absolute sizes, nothing in the output of vmstat -m, except
> solaris, is even approaching the sizes we are talking about (everything
> is a handful of megs at most).
> 
> Watching "top" during the rsync I can see wired memory steadily
> increasing. Starting at about 110 megs or so after startup (including
> parts of my desktop), it begins consistently increasing when I run the
> rsync. in this case I started to approach 200 megs. When rsync was done
> (ran it with -v this time) reading the source directory and began
> copying files, the growth of wired memory increased significantly in
> speed (it was up to 280 MB or so in under 30 seconds).
> 
> Killing rsync did not cause the wired total to go down.
> 
> Any suggestions on whether there is something else to monitor to find
> out what is using all the memory?
> 
> zfs_kmem_alloc() always allocates with M_SOLARIS.
> kmem_cache_{create,alloc} don't, but they seem to be allocating very
> small amounts of memory (could there be leakage of a huge number of
> these?). Is it expected that ZFS would allocate significant amount of
> memory that is not categorized as M_SOLARIS?
> 
> Could there be fragmentation going on? Are there very large allocations,
> relative to the 320 MB kmem size, intermixed with small allocations?
> 
> Anything I can do in terms of testing that would help debug this, beyond
> what has already been done and reported on on -current?

What you're seeing is probably another problem, which was described
already. Try tunning kern.maxvnodes down to 3/4 of the current value,
see if that helps and please report back.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd_at_FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!