Why is NFSv4 so slow?

[Rick Macklem]

> 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 <server>:/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