tuning NFS for a write heavy environment

David A. Bandel david.bandel at gmail.com
Fri Sep 26 17:23:28 PDT 2008


On Fri, Sep 26, 2008 at 9:15 AM, Lonni J Friedman <netllama at gmail.com> wrote:

[snip]

>
> /home is the only NFS mount point being exported.  They're compiling C
> code across the NFS mount.
>
>>

[snip]

>
> The system isn't bandwidth limited.  It has a dedicated gigabit NIC
> just for the NFS traffic, and its never coming even close to
> saturating the interface.

Good. This is usually the biggest problem, but you don't have it.

>
>>
>>>
>>> The server itself has a Athlon64X2-6400 (3.2Ghz) CPU, with 2GB of RAM.
>>>  Its not swapping at all.
>>

[snip]

>
> Doesn't Linux default to async ?  Anyway, I'm using the default.

Depends on which version you're using.

Up to and including the 1.0.0 release of nfs-utils sync was the
default.  Try running exportfs and see if it complains.  If so, you
should specify one or the other.  Async is faster but subject to
corruption errors if the server crashes.  You are now supposed to
explicitly state which you want.

I you use sync (despite the potential problems, I recommend async on a
reliable network), then use no_wdelay (no write delay -- this will
unblock nfs even though changes aren't committed to disk).

If your /home on your server isn't on its own partition, I would
suggest no_subtree_check to speed things up (albeit with possible
security implications).  Subtree checks is default, so you need to put
it in.

>
>>
>> Are they all writing to the same files? (file-locking issues?)
>
> No, each person has their own account in /home, with their own files.
>

I don't see a heavy NFS environment here, you're not pushing it, so
that shouldn't be a problem.  The compiles are happening on the
developer's machines (so they're probably swapping), and the large
number of nfs processes is probably due to fast open *.c for read,
write obj file, link and write linked file.  This won't cause the
server any grief -- names aren't changing while reading.  And like
memory usage in UNIX, as long as we have space, we don't reclaim it
right away to make subsequent accesses faster.

What do you see that suggests you need to optimize nfs beyond the
defaults (which are basically a sane mix of security then speed)?

Ciao,

David A. Bandel
-- 
Focus on the dream, not the competition.
            - Nemesis Air Racing Team motto



More information about the Linux-users mailing list