NFS Performance issue against NetApp

Rick Macklem rmacklem at uoguelph.ca
Thu Apr 25 00:36:56 UTC 2013


Jeremy Chadwick wrote:
> On Wed, Apr 24, 2013 at 04:08:24PM -0700, Marc G. Fournier wrote:
> >
> > On 2013-04-24, at 16:02 , Rick Macklem <rmacklem at uoguelph.ca> wrote:
> >
> > >>
> > > Along with rsize,wsize you might want to try increasing readahead.
> > > The
> > > default is only 1.
> >
> > Stupid question on this, possibly, but are the current defaults
> > "sane" anymore, or residual from 'the old days'? Like, I've read in
> > many places where you should raise rsize/wsize � in what
> > circumstances would leaving as the defaults make sense?
> 
> From what I can discern, the defaults on stable/9 (for an NFS client)
> are 8192 -- see sys/nfsclient/nfs.h, NFS_WSIZE and NFS_RSIZE.
> 
For the new client, it defaults to the min(MAXBSIZE, server-max), where
server-max is whatever the server says is its maximum (also MAXBSIZE for
the new server). I think the old server uses 32768.
These numbers are for the default tcp mounts. Specify udp (or mntudp) and
I think the default becomes 16384.

If you explicitly set rsize=N,wsize=N on a mount, those sizes will be
used unless they are greater than min(MAXBSIZE, server-max). MAXBSIZE is
the limit for the client side buffer cache and server-max is whatever
the server says is its max, so the client never uses a value greater than
that.

For readahead, the default is 1. This seems rather small to me and I think is
in the "from the old days" category. You can set it to
a larger value, although there is an ifdef'd upper limit, which is what
you'll get if you specify a really large value for readahead. Admittedly,
if you are using a large rsize,wsize on a low latency LAN, readahead=1
may be sufficient.

As someone else noted, if you are using head or stable/9, "nfsstat -m"
shows you what is actually being used, for the new client only.

rick

> --
> | Jeremy Chadwick jdc at koitsu.org |
> | UNIX Systems Administrator http://jdc.koitsu.org/ |
> | Mountain View, CA, US |
> | Making life hard for others since 1977. PGP 4BD6C0CB |


More information about the freebsd-fs mailing list