neil@ist.UUCP (Neil Todd) (10/09/87)
I want to tune up my NFS. Specifically - the read/write size, retry
and timeout counts.
The standard advice seems to be ``suck it and see'' (I assume that
translates into U.S. English). This seems most unsatisfactory, there
surely must be a more scientific approach.
Obviously the environment is a major factor, if for example the
principle use of a nfs mounted filesytem is for a database system to
access it data, and it always does read and writes of a standard size
then clearly there is a good starting point. But what about a more mixed
environment ? How could I monitor things, so that as the nature of the
use of the link changes with time I can see, reasonably quickly, whether
I should reconsider the values of [rw]size etc.
Words of wisdom will be much appreciated here. Hopefully the answers
won't include making kernel hacks as the majority of sites don't have
source, but if this is the only way - please say so, at least source
sites can do something then.
Neil Todd
[neil@ist.co.uk <- preferred
[neil@ist.uucp
[{backbone}!ukc!ist.co.uk!neil
Disclaimer: Own opinions, not necessarily those of employer etc, etc.hedrick@topaz.rutgers.edu (Charles Hedrick) (10/13/87)
Re NFS tuning: As far as I know, the default read and write sizes are fine when they work. They are available as an option, not for tuning, but because certain machines and gateways can't handle 6 packets with minimal spacing. For those machines, rsize and wsize have to be specified as having a smaller than normal value. Generally this problem is obvious if you have it. Users see lots of "NFS timeout, retrying..." messages. Similarly, as far as I know the default timeout values would be OK as long as you are on a single Ethernet, or on networks connected by high-speed gateways. The main situation where you would change them is if your network has something that would cause longer than normal response times. You can use "nfsstat" to see whether you are seeing timeouts and retransmissions. If so, try to figure out whether they are due to packets being dropped or whether you network has delays in it such that packets genuinely take longer to be acknowledged than the current timeout values. If the latter, then increase the timeout specifications.