Date: Mon, 5 Jul 2010 23:38:29 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: "Rick C. Petty" <rick-freebsd2009@kiwi-computer.com> Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? Message-ID: <Pine.GSO.4.63.1007052332020.7410@muncher.cs.uoguelph.ca> In-Reply-To: <20100627221607.GA31646@kay.kiwi-computer.com> References: <20100627221607.GA31646@kay.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.1007052332020.7410>