From owner-freebsd-stable@FreeBSD.ORG Mon Jun 28 23:32:06 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 ABB701065732 for ; Mon, 28 Jun 2010 23:32:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5168FC13 for ; Mon, 28 Jun 2010 23:32:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFfNKEyDaFvJ/2dsb2JhbACfNnHBCoUkBA X-IronPort-AV: E=Sophos;i="4.53,499,1272859200"; d="scan'208";a="82195603" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 28 Jun 2010 19:32:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 52302FB80DA; Mon, 28 Jun 2010 19:32:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvYK8RNrnqcz; Mon, 28 Jun 2010 19:32:04 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 58A4AFB80BD; Mon, 28 Jun 2010 19:32:04 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o5SNmxP14973; Mon, 28 Jun 2010 19:48:59 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 28 Jun 2010 19:48:59 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "Rick C. Petty" In-Reply-To: <20100628153527.GB53315@kay.kiwi-computer.com> Message-ID: References: <20100627221607.GA31646@kay.kiwi-computer.com> <20100628031401.GA45282@kay.kiwi-computer.com> <20100628034741.GA45748@kay.kiwi-computer.com> <20100628153527.GB53315@kay.kiwi-computer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 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 23:32:06 -0000 On Mon, 28 Jun 2010, Rick C. Petty wrote: > 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. > Ok, it sounds like you found some kind of race condition in the delegation handling. (I'll see if I can reproduce it here. It could be fun to find:-) > 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. > Hmm, see below w.r.t. 100% cpu. > 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. > It would be interesting to see if the performance problem exists for NFSv3 mounts against the experimental (nfsv4) server. Since the CPUs are 100% busy, it might be a scheduling issue w.r.t. the nfsd threads (ie. the ones in the experimental server don't have as high a priority as for the regular server?). I've always tested on a machine where the CPU (I only have single core) are nowhere near 100% busy. If this theory is correct, the performance issue should still be noticible for an NFSv3 mount to the experimental server. I'll try running something compute bound on the server here and see what happens. rick