From owner-freebsd-stable@FreeBSD.ORG Mon Jun 28 15:35:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCE39106564A for ; Mon, 28 Jun 2010 15:35:28 +0000 (UTC) (envelope-from rick@svn.kiwi-computer.com) Received: from svn.kiwi-computer.com (174-20-59-6.mpls.qwest.net [174.20.59.6]) by mx1.freebsd.org (Postfix) with SMTP id 530388FC1F for ; Mon, 28 Jun 2010 15:35:27 +0000 (UTC) Received: (qmail 53634 invoked by uid 2000); 28 Jun 2010 15:35:27 -0000 Date: Mon, 28 Jun 2010 10:35:27 -0500 From: "Rick C. Petty" To: Rick Macklem Message-ID: <20100628153527.GB53315@kay.kiwi-computer.com> References: <20100627221607.GA31646@kay.kiwi-computer.com> <20100628031401.GA45282@kay.kiwi-computer.com> <20100628034741.GA45748@kay.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 15:35:28 -0000 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). > > 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