Date: Mon, 28 Jun 2010 10:35:27 -0500 From: "Rick C. Petty" <rick-freebsd2009@kiwi-computer.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? Message-ID: <20100628153527.GB53315@kay.kiwi-computer.com> In-Reply-To: <Pine.GSO.4.63.1006280032180.2680@muncher.cs.uoguelph.ca> References: <20100627221607.GA31646@kay.kiwi-computer.com> <Pine.GSO.4.63.1006271949220.3233@muncher.cs.uoguelph.ca> <20100628031401.GA45282@kay.kiwi-computer.com> <20100628034741.GA45748@kay.kiwi-computer.com> <Pine.GSO.4.63.1006280032180.2680@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 28, 2010 at 12:35:14AM -0400, Rick Macklem wrote: > > Being stuck in "newnfsreq" means that it is trying to establish a TCP > connection with the server (again smells like some networking issue). > <snip> > Disabling delegations is the next step. (They aren't > required for correct behaviour and are disabled by default because > they are the "greenest" part of the implementation.) After disabling delegations, I was able to build world and kernel on two different clients, and my port build problems went away as well. I'm still left with a performance problem, although not quite as bad as I originally reported. Directory listings are snappy once again, but playing h264 video is choppy, particularly when seeking around: there's almost a full second delay before it kicks in, no matter where I seek. With NFSv3 the delay on seeks was less than 0.1 seconds and the playback was never jittery. I can try it again with v3 client and v4 server, if you think that's worthy of pursuit. If it makes any difference, the server's four CPUs are pegged at 100% (running "nice +4" cpu-bound jobs). But that was the case before I enabled v4 server too. -- Rick C. Petty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100628153527.GB53315>