NFS optimization

[David Gilbert]

>>>>> "Eric" == Eric Anderson <anderson at centtech.com> writes:

Eric> David Gilbert wrote:

>> Consider that if you are "out" of nfsd's, the penalty is increased
>> latency for some small number of transactions that wait for an nfsd
>> to become available..  Even if you have tonnes of NFSd processes,
>> if disk is a limiting factor, more nfsd's won't speed the process.


Eric> I have found that having too little can easily cause clients to
Eric> block on nfs under peak usage times, so I tend to bump the
Eric> number way up.  There's little to no harm in it.

I have never, ever seen this behaviour.  I'd go as far as to say that
it shouldn't happen.  Not categorically, but NFS packets should be
entirely independant... meaning it shouldn't prefer one client's
pakcets over another unless it is massively starved for NFSd's, the
queue should be somewhat FIFO.

Eric> I usually look at my nfsd's, and see what the distribution of
Eric> run time is on them.  I like to see at minimum a few (maybe 5%
Eric> or so) with 0:00.00 runtime - which (to me) means that I had
Eric> enough to service the queue, and a few extra that were bored.
Eric> For my setup, this means typically between 256 and 512 nfsd's
Eric> (with one server at 1024).

I have run incredibly busy NFS servers (20 to 40 disks, 16 to 20
ethernet and 100 (or more) busy diskless clients (computation cluster)
and I have never run more than 32.  I've never found a performance
advantage beyond 1:1 nfsd's to disks.

Dave.

-- 
============================================================================
|David Gilbert, Independent Contractor.       | Two things can be          |
|Mail:       dave at daveg.ca                    |  equal if and only if they |
|http://daveg.ca                              |   are precisely opposite.  |
=========================================================GLO================