Linux NFS development
 help / color / mirror / Atom feed
From: Chris Penney <cpenney@gmail.com>
To: nfs@lists.sourceforge.net
Cc: Jeff Block <jblock@mrsc.ucsf.edu>
Subject: Re: NFS Performance issues
Date: Wed, 11 May 2005 10:15:25 -0400	[thread overview]
Message-ID: <111aefd05051107151d4624b8@mail.gmail.com> (raw)
In-Reply-To: <BEA6E6AA.11AD0%jblock@mrsc.ucsf.edu>

> We have 683MB of test data that we were playing with that represents the
> file sizes that our users play with.  There are several small files in th=
is
> set so there is a lot of writes and commits.  Our users generally work wi=
th
> data sets in the multiple gigabyte range.

This sounds similar to some of the CAE analysis work that some of the
NFS servers I maintain handle.  Our Sun 480s w/ Veritas do a
reasonable job, but the linux boxes we have blow their doors off.

We are using JFS file systems (which was a huge improvement for us)
and using the 2.6 device-mapper to stripe across four 1TB luns.  We
have dual cpu boxes w/ hyperthreading enabled and use 128 nfs threads.
 All clients use a 32k r/wsize (which was also an improvement).  We
don't use async for reliability reasons (I'm not sure with out setup
it would matter than much).

I aslo use the following in sysctl.conf:

net.core.rmem_default =3D 262144
net.core.wmem_default =3D 262144
net.core.rmem_max =3D 8388608
net.core.wmem_max =3D 8388608
net.ipv4.tcp_rmem =3D 4096 87380 8388608
net.ipv4.tcp_wmem =3D 4096 65536 8388608
net.ipv4.tcp_mem =3D 8388608 8388608 8388608

I can't say those tuneing options are formally tested.  Perhaps
something with more understand could comment on them.

   Chris


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  parent reply	other threads:[~2005-05-12  1:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-11  5:31 NFS Performance issues Jeff Block
2005-05-11  6:14 ` Neil Brown
2005-05-11 14:15 ` Chris Penney [this message]
2005-05-11 17:25 ` Dan Stromberg
  -- strict thread matches above, loose matches on Subject: below --
2002-03-15 23:44 Matt Heaton
2002-03-16 15:34 ` Thomas Langås
2002-03-16 16:54   ` Matt Heaton
2002-03-16 17:35     ` Thomas Langås

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=111aefd05051107151d4624b8@mail.gmail.com \
    --to=cpenney@gmail.com \
    --cc=jblock@mrsc.ucsf.edu \
    --cc=nfs@lists.sourceforge.net \
    --cc=penney@msu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox