Date: Mon, 9 Apr 2007 21:55:23 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Craig Boston <craig@xfoil.gank.org>, Kris Kennaway <kris@obsecurity.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: <20070410015523.GA39181@xor.obsecurity.org> In-Reply-To: <20070410014233.GD8189@nowhere> References: <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> <20070410003837.GB8189@nowhere> <20070410011125.GB38535@xor.obsecurity.org> <20070410013034.GC8189@nowhere> <20070410014233.GD8189@nowhere>
next in thread | previous in thread | raw e-mail | index | archive | help
--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Apr 09, 2007 at 08:42:33PM -0500, Craig Boston wrote:
> On Mon, Apr 09, 2007 at 08:30:35PM -0500, Craig Boston wrote:
> > Even the vm.zone breakdown seems to be gone in current so apparently my
> > knowledge of such things is becoming obsolete :)
>=20
> But vmstat -m still works
>=20
> ...
>=20
> solaris 145806 122884K - 15319671 16,32,64,128,256,512,1024,2048,40=
96
> ...
>=20
> Whoa! That's a lot of kernel memory. Meanwhile...
>=20
> kstat.zfs.misc.arcstats.size: 33554944
> (which is just barely above vfs.zfs.arc_min)
>=20
> So I don't think it's the arc cache (yeah I know that's redundant) that
> is the problem. Seems like something elsewhere in zfs is allocating
> large amounts of memory and not letting it go, and even the cache is
> having to shrink to its minimum size due to the memory pressure.
>=20
> It didn't panic this time, so when the tar finished I tried a "zfs
> unmount /usr/ports". This caused the "solaris" entry to drop down to
> about 64MB, so it's not a leak. It could just be that ZFS needs lots of
> memory to operate if it keeps a lot of metadata for each file in memory.
>=20
> The sheer # of allocations still seems excessive though. It was well
> over 20 million by the time the tar process exited.
That is a lifetime count of the # of operations, not the current
number allocated ("InUse").
It does look like there is something else using a significant amount
of memory apart from arc, but arc might at least be the major one due
to its extremely greedy default allocation policy.
Kris
--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFGGu6LWry0BWjoQKURAsvPAJ9RQY1byjCO6m2ffTfKNdcal+MHqgCfXipe
L730fhNTz/IegK/hc1PK+/g=
=dFbw
-----END PGP SIGNATURE-----
--OXfL5xGRrasGEqWY--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070410015523.GA39181>