Date: Mon, 30 Apr 2007 23:28:22 +0200 From: Peter Schuller <peter.schuller@infidyne.com> To: Craig Boston <craig@xfoil.gank.org>, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, freebsd-fs@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. Message-ID: <46365F76.7090708@infidyne.com> In-Reply-To: <20070410003505.GA8189@nowhere> References: <20070406025700.GB98545@garage.freebsd.pl> <20070407025644.GC8831@cicely12.cicely.de> <20070407131353.GE63916@garage.freebsd.pl> <4617A3A6.60804@kasimir.com> <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF04CD83DED20F6D94E36C095
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
> 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?
--=20
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org
--------------enigF04CD83DED20F6D94E36C095
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGNl9+DNor2+l1i30RCCk+AJ9CyO17c6ESWugBGb0aerpN7VtTjACgxkUK
wuINyXFIiLUa88294i9S77M=
=NDfk
-----END PGP SIGNATURE-----
--------------enigF04CD83DED20F6D94E36C095--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46365F76.7090708>