[ale] Slow NFS Speed?

Michael H. Warfield mhw at WittsEnd.com
Thu Sep 15 11:39:34 EDT 2011


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!
-------------- 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/2b941646/attachment.bin 


More information about the Ale mailing list