Re: ZFS leaking vnodes (sort of)

From: Huang wen hui <huang_at_gddsn.org.cn>
Date: Mon, 09 Jul 2007 20:43:33 +0800
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!
Received on Mon Jul 09 2007 - 21:14:17 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:14 UTC