Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Aug 2010 11:44:06 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        rick-freebsd2009@kiwi-computer.com
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Why is NFSv4 so slow?
Message-ID:  <2002105637.244211.1283096646412.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <20100829032252.GA81736@rix.kiwi-computer.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.

First off, the obvious question: How does this client differ from the
one that performs much better?
Do they both use the same "re" network interface for the NFS traffic?
(If the answer is "no", I'd be suspicious that the "re" hardware or
device driver is the culprit.)

Things that I might try in an effort to isolate the problem:
- switch the NFS traffic to use the nfe0 net interface.
- put a net interface identical to the one on the client that
  works well in the machine and use that for the NFS traffic.
- turn off TXCSUM and RXCSUM on re0
- reduce the read/write data size, using rsize=N,wsize=N on the
  mount. (It will default to MAXBSIZE and some net interfaces don't
  handle large bursts of received data well. If you drop it to
  rsize=8192,wszie=8192 and things improve, then increase N until it
  screws up.)
- check the port configuration on the switch end, to make sure it
  is also 1000bps-full duplex.
- move the client to a different net port on the switch or even a
  different switch (and change the cable, while you're at it).
- Look at "netstat -s" and see if there are a lot of retransmits
  going on in TCP.

If none of the above seems to help, you could look at a packet trace
and see what is going on. Look for TCP reconnects (SYN, SYN-ACK...)
or places where there is a large time delay/retransmit of a TCP
segment.

Hopefully others who are more familiar with the networking side
can suggest other things to try, rick




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2002105637.244211.1283096646412.JavaMail.root>