From owner-freebsd-stable@FreeBSD.ORG Tue Aug 31 02:24:52 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 5192D1065672 for ; Tue, 31 Aug 2010 02:24:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1241F8FC16 for ; Tue, 31 Aug 2010 02:24:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEABYFfEyDaFvO/2dsb2JhbACDFp5ErTSRfoEigyJzBIoJ X-IronPort-AV: E=Sophos;i="4.56,295,1280721600"; d="scan'208";a="92289825" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 Aug 2010 22:24:50 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6F7F1B3EA3; Mon, 30 Aug 2010 22:24:50 -0400 (EDT) Date: Mon, 30 Aug 2010 22:24:50 -0400 (EDT) From: Rick Macklem To: rick-freebsd2009@kiwi-computer.com Message-ID: <257768957.302339.1283221490386.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100830172259.GA20421@rix.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) 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: Tue, 31 Aug 2010 02:24:52 -0000 > On Sun, Aug 29, 2010 at 11:44:06AM -0400, Rick Macklem wrote: > > > Hi. I'm still having problems with NFSv4 being very laggy on one > > > client. > > > When the NFSv4 server is at 50% idle CPU and the disks are < 1% > > > busy, > > > I am > > > getting horrible throughput on an idle client. Using dd(1) with 1 > > > MB > > > block > > > size, when I try to read a > 100 MB file from the client, I'm > > > getting > > > around 300-500 KiB/s. On another client, I see upwards of 20 MiB/s > > > with > > > the same test (on a different file). On the broken client: > > > > Since other client(s) are working well, that seems to suggest that > > it > > is a network related problem and not a bug in the NFS code. > Oh, one more thing...Make sure that the user and group name/number space is consistent across all machines and nfsuserd is working on them all. (Look at "ls -lg" on the clients and see that the correct user/group names are showing up.) If this mapping isn't working correctly, it will do an upcall to the userland nfsuserd for every RPC and that would make NFSv4 run very slowly. It will also use the domain part (after first '.') of each machine's hostname, so make sure that all the hostnames (all clients and server) are the same. ie: server.cis.uoguelph.ca, client1.cis.uoguelph.ca,... are all .cis.uoguelph.ca. If that is the problem # mount -t newnfs -o nfsv3 :/path /mnt will work fine, since NFSv3 doesn't use the mapping daemon. > > Is that something easily scriptable with tcpdump? I'd rather not look > for such things manually. > I've always done this manually and, although tcpdump can be used to do the packet capture, wireshark actually understands NFS packets and, as such, is much better for looking at the packets. rick