system slowdown - vnode related

[David Schultz]

On Mon, Jun 09, 2003, Masachika ISHIZUKA wrote:
> >>   I have still vnodes problem in 4.8-stable with /sys/kern/vfs_subr.c
> >> 1.249.2.30.
> >> 
> >> (1) #1 machine (Celeron 466 with 256 mega byte rams)
> >> 
> >>   % sysctl kern.maxvnodes
> >>   kern.maxvnodes: 17979
> >>   % sysctl vm.zone | grep VNODE
> >>   VNODE:           192,        0,  18004,    122,    18004
> > 
> > This looks pretty normal to me for a quiescent system.
> 
>   Hi, David-san.
>   Thank you for mail.
>   I think the used(18004) exceeds maxvnodes(17979), isn't it ?

Only by a little bit.  maxvnodes isn't a hard limit, since making
it a hard limit would lead to deadlocks.  Instead, the system
garbage collects vnodes to keep the number roughly in line with
maxvnodes.  Judging by the numbers above, it's doing a pretty good
job, but that's probably because, from the looks of it, you
just booted the system.

The reason it might make sense to increase maxvnodes is that
having vnlru work overtime to keep your vnode count low may
result in vnodes being freed that are still needed, e.g. by the
buffer cache.  This would cause the slowdown you were mentioning.

(As a disclaimer, Tor Egge and Matt Dillon know far more about
this than I do.)

> > I would actually suggest raising maxvnodes if you have lots of
> > little files.  Does the number of vnodes shoot up when 310.locate
> > runs?
> 
>   The value shown above is the value at slow down time of 310.locate.
> The number of used vnodes is low at boot up until 310.locate invoked.
> 
> > Did you get a backtrace from the panics?
> 
>   It's too hard for me. Is there any way to do it ?

The panics might be unrelated to the number of vnodes, so it's
important that we have additional information.  See:

http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html