2004-07-27 15:10:55

by Norman Weathers

[permalink] [raw]
Subject: Some questions regarding NFS over TCP


I have been on the list only for a short time now, and I have started some
research, but have noticed that some of the documentation is slightly out of
date, and had a couple of questions regarding NFS over TCP. If there is some
new info, please point me to it so that I don't take up the mailing list
bandwidth.

Information about nodes:

Servers - Various P3 nodes running from 600MHz to 2.4 GHz. 600 MHz nodes are
bonded 100 MB fast ethernet, other servers are all single GB connection. All
servers running RedHat 7.3 with 2.4.21 kernel and Trond NFS all patch.

Clients - Various P3, P4, and Athlons. Some nodes have single 100 MB
connections back to switches, others have GB back to switches. All nodes
runinng RedHat 2.4.26 with Trond NFS all patch.


All nodes running nfs-utils-1.0.1-1.


1) We have a decent sized cluster utilizing NFS. We currently use udp as the
transport protocol. One of the issues that we have is when running sync
transfers are slow. We recently moved to async in the /etc/exports on the
servers. This has helped some, but we still have some performance issues (I
know that the server nodes can do more than 10 - 15 MB / sec NFS traffic).
One of the things that I have seen alot of on the list lately is the use of
TCP. I have read the older documentation concerning NFS over TCP, and was
wondering if the old disadvantages and advantages still hold true (ie,
advantage: GB servers to 100 MB clients better transfer rates, disadvantage:
Server crash requires unmount of all cluster nodes that had the NFS server
mounted).

2) Should we see a large difference between sync and async NFS mounted
servers?

Thanks in advance. Like I said, if this has been discussed recently, please
let me know, and I will look up the discussion thread.
--

Norman Weathers
SIP Linux Cluster
TCE UNIX
ConocoPhillips
Houston, TX

Office: LO2003
Phone: ETN 639-2727
or (281) 293-2727


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs


2004-07-27 16:53:14

by Stuckless, Colin

[permalink] [raw]
Subject: RE: Some questions regarding NFS over TCP

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]
> Sent: Tuesday, July 27, 2004 12:41 PM
> To: [email protected]
> Subject: [NFS] Some questions regarding NFS over TCP
>
>
> 1) We have a decent sized cluster utilizing NFS. We
> currently use udp as the transport protocol. One of the
> issues that we have is when running sync transfers are
> slow. We recently moved to async in the /etc/exports
> on the servers. This has helped some, but we still have
> some performance issues (I know that the server nodes can
> do more than 10 - 15 MB / sec NFS traffic).
> One of the things that I have seen alot of on the list lately
> is the use of TCP. I have read the older documentation
> concerning NFS over TCP, and was wondering if the old
> disadvantages and advantages still hold true (ie,
> advantage: GB servers to 100 MB clients better transfer
> rates, disadvantage:
> Server crash requires unmount of all cluster nodes that had
> the NFS server
> mounted).

> Norman Weathers
> SIP Linux Cluster
> TCE UNIX
> ConocoPhillips
> Houston, TX


Norman,

FWIW, my experience is with Solaris servers and Linux clients.
NFS over UDP may give you a small performance increase
in the general case, but it only takes one lost packet
to go from having a well behaved NFS environment to one
that will have you pulling your hair out trying to figure
out what's causing the intermittent performance problems.

The 100Mbit benchmarks I've run on TCP vs. UDP with Solaris as
the server and Linux as the client showed very similar
read/write speeds. If you ramp the wsize/rsize up on
the UDP mounts perhaps you can get a bit more throughput, but
then I found that 32K or larger rsize/wsize was not
reliable (one of the Linux client machines would eventually
bring the Solaris server to a near grinding halt during
heavy writes, like when running a seismic job). It could
takes days or weeks before you'd see a problem, but
eventually I always saw a problem when running UDP and
going above 8K rsize/wsize.

I think the documentation is maybe outdated - I think everyone
should be using TCP. Flow control is important, and TCP
does it much better than the recovery mechanism built
into NFS.


Colin Stuckless
[email protected]








********************

This email communication is intended as a private communication for the sole
use of the primary addressee and those individuals listed for copies in the
original message. The information contained in this email is private and
confidential and If you are not an intended recipient you are hereby
notified that copying, forwarding or other dissemination or distribution of
this communication by any means is prohibited. If you are not specifically
authorized to receive this email and if you believe that you received it in
error please notify the original sender immediately. We honour similar
requests relating to the privacy of email communications.

Cette communication par courrier ?lectronique est une communication priv?e ?
l'usage exclusif du destinataire principal ainsi que des personnes dont les
noms figurent en copie. Les renseignements contenus dans ce courriel sont
confidentiels et si vous n'?tes pas le destinataire pr?vu, vous ?tes avis?,
par les pr?sentes que toute reproduction, transfert ou autre forme de
diffusion de cette communication par quelque moyen que ce soit est
interdite. Si vous n'?tes pas sp?cifiquement autoris? ? recevoir ce
courriel ou si vous croyez l'avoir re?u par erreur, veuillez en aviser
l'exp?diteur original imm?diatement. Nous respectons les demandes
similaires qui touchent la confidentialit? des communications par courrier
?lectronique.