[ale] Slow NFS Speed?

Michael H. Warfield mhw at WittsEnd.com
Thu Sep 15 12:51:03 EDT 2011


On Thu, 2011-09-15 at 16:02 +0000, Lightner, Jeff wrote:
> Curious: If NFS is known to be slow for read/writes does it make sense
> to use CIFS/samba for backup destinations instead even if no Windoze
> server involved? Or does it have the same limitations?

Unfortunately, all I can really say is that it's different (so sayeth a
former maintainer of smbmount and smbfs before we deprecated it in favor
of the cifs file system and mount.cifs).

CIFS shares some of the same problems with all of the "network file
systems" in that you're not merely moving a data stream across a network
but are supporting a full random-access file system and protocol.  It
does NOT have some of the problems of NFS.  It DOES have some of its own
problems.  They don't work the same way.  CIFS has this concept of a
user related session while NFS is largely a stateless transport
supporting multiple users simultaneously.  So it's difficult to compare
the two and performance can be a crap shoot either way.

If you can get at it, you might try sshfs, which is an ssh and FUSE
based file system:

http://fuse.sourceforge.net/sshfs.html

Again, though, your mileage may (and will) vary.  All you can do is try
it out and see.  Downside is that it IS a user space file system so that
too can be a performance hog.

Regards,
Mike

> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Michael H. Warfield
> Sent: Thursday, September 15, 2011 11:40 AM
> To: Atlanta Linux Enthusiasts
> Cc: mhw at wittsend.com
> Subject: Re: [ale] Slow NFS Speed?
> 
> On Thu, 2011-09-15 at 11:26 -0400, David Tomaschik wrote:
> > On Thu, Sep 15, 2011 at 11:10 AM, Ed Cashin <ecashin at noserose.net> wrote:
> > > Wild guess: Client is mounting with the "sync" option?
> > >
> > > The sync export option on the server is needed and normal, but the client
> > > mount option really slows things down and isn't proportionately helpful.
> > >
> > > Providing more details (stuff like `cat /proc/mounts`) will help folks give
> > > you less wild guesses.  ;)
> >
> > Good point -- not enough coffee in me yet this morning.  IP addresses
> > changed to protect the innocent.
> >
> > xserve:/Volumes/VTrak /mnt/VTrak nfs
> > rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.1.1.53,mountvers=3,mountproto=tcp,addr=10.1.1.53 0 0
> 
> Woah...  Is there some particular reason why you want to be using TCP?
> Have you tried comparing performance with UDP?  Sometimes, TCP can make
> performance worse, especially when you're talking about an RPC based
> protocol with its own layer of redundancy and recovery, like NFS.
> 
> Not totally sure if it would be better or worse but it would be nice to
> know the contrast.
> 
> Regards,
> Mike
> 
> > NFS Stat:
> >
> > # nfsstat
> > Server rpc stats:
> > calls      badcalls   badauth    badclnt    xdrcall
> > 17519673   0          0          0          0
> >
> > Server nfs v3:
> > null         getattr      setattr      lookup       access       readlink
> > 69        0% 11065566 63% 19642     0% 49364     0% 241549    1% 5         0%
> > read         write        create       mkdir        symlink      mknod
> > 21849     0% 3045148  17% 6084      0% 723       0% 3         0% 0         0%
> > remove       rmdir        rename       link         readdir      readdirplus
> > 1676      0% 42        0% 820       0% 114       0% 61        0% 6292      0%
> > fsstat       fsinfo       pathconf     commit
> > 124314    0% 112       0% 63        0% 2931595  16%
> >
> > Client rpc stats:
> > calls      retrans    authrefrsh
> > 12980703   0          0
> >
> > Client nfs v3:
> > null         getattr      setattr      lookup       access       readlink
> > 0         0% 116983    0% 0         0% 69601     0% 39658     0% 0         0%
> > read         write        create       mkdir        symlink      mknod
> > 12745216 98% 0         0% 0         0% 0         0% 0         0% 0         0%
> > remove       rmdir        rename       link         readdir      readdirplus
> > 0         0% 0         0% 0         0% 0         0% 428       0% 8740      0%
> > fsstat       fsinfo       pathconf     commit
> > 73        0% 2         0% 1         0% 0         0%
> >
> >
> > >
> > > On Thu, Sep 15, 2011 at 10:43 AM, David Tomaschik <david at systemoverlord.com>
> > > wrote:
> > >>
> > >> At work, we have an OS X 10.5 NFS server with a Ubuntu Server 10.04
> > >> client.  (Among others.)  We're running backups via NFS using Amanda,
> > >> and the backups seem to be pegging at exactly 100Mbit/s.  Both
> > >> machines are connected via GigE, full-duplex.  (Confirmed via mii-tool
> > >> and system preferences.)
> > >>
> > >> I can read from the storage array on the XServe at ~200MB/s via dd.
> > >> Additionally, Amanda can read from clients remotely (SSH transport) at
> > >> 400-500 Mbit/s, so it doesn't seem to be an issue with the backup
> > >> server.
> > >>
> > >> I've tried tweaking NFS rsize with no noticeable impact.  Any other
> > >> hints to improve NFS performance?  Anyone with experience with OS X as
> > >> an NFS host?  Most of the information I find online is OS X as an NFS
> > >> client.
> >
> >
> >
> >
> > --
> > David Tomaschik, RHCE, LPIC-1
> > System Administrator/Open Source Advocate
> > OpenPGP: 0x5DEA789B
> > http://systemoverlord.com
> > david at systemoverlord.com
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> >
> 
> --
> Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
>    /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
>    NIC whois: MHW9          | An optimist believes we live in the best of all
>  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
> 
> 
> 
> Proud partner. Susan G. Komen for the Cure.
> 
> 
> Please consider our environment before printing this e-mail or attachments.
> 
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
> ----------------------------------
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110915/d5fb8e92/attachment-0001.bin 


More information about the Ale mailing list