Why is NFSv4 so slow?

[Rick Macklem]

On Sun, 27 Jun 2010, Rick C. Petty wrote:

> First off, many thanks to Rick Macklem for making NFSv4 possible in
> FreeBSD!
>
> I recently updated my NFS server and clients to v4, but have since noticed
> significant performance penalties.  For instance, when I try "ls a b c" (if
> a, b, and c are empty directories) on the client, it takes up to 1.87
> seconds (wall time) whereas before it always finished in under 0.1 seconds.
> If I repeat the test, it takes the same amount of time in v4 (in v3, wall
> time was always under 0.01 seconds for subsequent requests, as if the
> directory listing was cached).
>
> If I try to play an h264 video file on the filesystem using mplayer, it
> often jitters and skipping around in time introduces up to a second or so
> pause.  With NFSv3 it behaved more like the file was on local disk (no
> noticable pauses or jitters).
>
I just came across a case where things get really slow during testing
of some experimental caching stuff. (It was caused by the experimental
stuff not in head, but...)

It turns out that if numvnodes > desiredvnodes, it sleeps for 1sec before
allocating a new vnode. This might explain your approx. 1sec delays.

When this happens, "ps axlH" will probably show a process sleeping on
"vlruwk" and desiredvnodes can be increased by setting a larger value
for kern.maxvnodes. (numvnodes can be seen as vfs.numvnodes)

I don't think there is actually a vnode leak, but you might find that
the experimental nfs subsystem is a vnode hog.

rick