From owner-freebsd-current@FreeBSD.ORG Mon Apr 30 21:31:19 2007 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B072116A401; Mon, 30 Apr 2007 21:31:19 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 1326613C483; Mon, 30 Apr 2007 21:31:16 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 36E7445B26; Mon, 30 Apr 2007 23:31:15 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0DAC545681; Mon, 30 Apr 2007 23:31:08 +0200 (CEST) Date: Mon, 30 Apr 2007 23:30:43 +0200 From: Pawel Jakub Dawidek To: Peter Schuller Message-ID: <20070430213043.GF67738@garage.freebsd.pl> 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> <46365F76.7090708@infidyne.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cz6wLo+OExbGG7q/" Content-Disposition: inline In-Reply-To: <46365F76.7090708@infidyne.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@FreeBSD.org, Craig Boston , freebsd-current@FreeBSD.org Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2007 21:31:19 -0000 --cz6wLo+OExbGG7q/ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > I am also/still seeing the "kmem_map too small" panic on a tree cvsup:ed > around April 27. >=20 > 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. >=20 > 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. >=20 > 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). >=20 > 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). >=20 > Killing rsync did not cause the wired total to go down. >=20 > Any suggestions on whether there is something else to monitor to find > out what is using all the memory? >=20 > 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? >=20 > Could there be fragmentation going on? Are there very large allocations, > relative to the 320 MB kmem size, intermixed with small allocations? >=20 > 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. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --cz6wLo+OExbGG7q/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGNmADForvXbEpPzQRAoSIAKC/vuP7XWzvba1h2MJOTI5iDTBZ6wCeLoDz isJ4AqbPWD6IYslc6ByUQPo= =Kopf -----END PGP SIGNATURE----- --cz6wLo+OExbGG7q/--