Date: Mon, 09 Jul 2007 20:43:33 +0800 From: Huang wen hui <huang@gddsn.org.cn> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: current@freebsd.org Subject: Re: ZFS leaking vnodes (sort of) Message-ID: <46922D75.4010006@gddsn.org.cn> In-Reply-To: <20070709000918.GD1208@garage.freebsd.pl> References: <200707071426.18202.dfr@rabson.org> <20070709000918.GD1208@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek дµÀ: > On Sat, Jul 07, 2007 at 02:26:17PM +0100, Doug Rabson wrote: > >> I've been testing ZFS recently and I noticed some performance issues >> while doing large-scale port builds on a ZFS mounted /usr/ports tree. >> Eventually I realised that virtually nothing ever ended up on the vnode >> free list. This meant that when the system reached its maximum vnode >> limit, it had to resort to reclaiming vnodes from the various >> filesystem's active vnode lists (via vlrureclaim). Since those lists >> are not sorted in LRU order, this led to pessimal cache performance >> after the system got into that state. >> >> I looked a bit closer at the ZFS code and poked around with DDB and I >> think the problem was caused by a couple of extraneous calls to vhold >> when creating a new ZFS vnode. On FreeBSD, getnewvnode returns a vnode >> which is already held (not on the free list) so there is no need to >> call vhold again. >> > > Whoa! Nice catch... The patch works here - I did some pretty heavy > tests, so please commit it ASAP. > > I also wonder if this can help with some of those 'kmem_map too small' > panics. I was observing that ARC cannot reclaim memory and this may be > because all vnodes and thus associated data are beeing held. > > To ZFS users having problems with performance and/or stability of ZFS: > Can you test the patch and see if it helps? > my T60p notebook, -CURRENT amd64: buildworld time before patch: 58xx second. buildworld time after path: 28xx second. Thanks!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46922D75.4010006>