vnode leak in FFS code ... ?
bsd at afields.ca
Wed Sep 1 18:35:35 PDT 2004
On Wed, Sep 01, 2004 at 05:12:06PM -0600, Scott Long wrote:
> Marc G. Fournier wrote:
> >On Wed, 1 Sep 2004, Allan Fields wrote:
> >>On Wed, Sep 01, 2004 at 03:19:27PM -0300, Marc G. Fournier wrote:
> >>>I don't know if this is applicable to -current as well, but so far,
> >>>anything like this I've uncovered in 4.x has needed an equivalent fix in
> >>>5.x, so figured it can't hurt to ask, especially with everyone working
> >>>towards a STABLE 5.x branch ... I do not have a 5.x machine running this
> >>>sort of load at the moment, so can't test, or provide feedback there ...
> >>>all my 5.x machines are more or less desktops ...
> >>>On Saturday, I'm going to try an unmount of the bigger file system,
> >>>to see
> >>>if it frees everything up without a reboot ... but if someone can
> >>>something to check to see if it is a) a leak and b) is fixable
> >>>between now
> >>>and then, please let me know ... again, this is a 4.10 system, but
> >>>most of
> >>>the work that Tor and David have done (re: vnodes) in the past
> >>>relating to
> >>>my servers have been applied to 5.x first, and MFC'd afterwards, so I
> >>>suspect that this too many be something that applies to both branches
> >>Unmounting the filesystems will call vflush() and should flush all
> >>vnodes from under that mount point. I'm not entirely sure if this
> >>is the best you can do w/o rebooting.
> >Understood, and agreed ... *but* ... is there a way, before I do that,
> >of determining if this is something that needs to be fixed at the OS
> >level? Is there a leak here that I can somehow identify while its in
> >this state?
> >The server has *only* been up 25 days
> It's really hard to tell if there is a vnode leak here. The vnode pool
> is fairly fluid and has nothing to do with the number of files that are
> actually 'open'. Vnodes get created when the VFS layer wants to access
> an object that isn't already in the cache, and only get destroyed when
> the object is destroyed. A vnode that reprents a file that was opened
> will stay 'active' in the system long after the file has been closed,
> because it's cheaper to keep it active in the cache than it is to
> discard it and then risk having to go through the pain of a namei()
> and VOP_LOOKUP() again later. Only if the maxvnode limit is hit will
> old vnodes start getting recycled to represent other objects. [...]
> So you've obviously bumped up kern.maxvnodes well above the limits that
> are normally generated from the auto-tuner. Why did you do that, if not
> because you knew that you'd have a large working set of referenced (but
> maybe not open all at once) filesystem objects? [...]
There was a pevious thread I've found which also helps explains
Really the same issue now as then?
> If unmounting the filesystem doesn't result in numvnodes decreasing,
> then there definitely might be a leak. Unfortunately, you haven't
> provided that kind of information yet.
Allan Fields, AFRSL - http://afields.ca
2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541
More information about the freebsd-current