Managing NFS and NIS, 2nd Edition - Mike Eisler [260]
Without the kernel's values as a baseline, choosing a new timeout value is best done empirically. Doubling the initial value is a good baseline; after changing the timeout value observe the RPC timeout rate and badxid rate using nfsstat. At first glance, it does not appear that there is any harm in immediately going to timeo=200, the maximum initial timeout value used in the retransmission algorithm. If server performance is the sole constraint, then this is a fair assumption. However, even a well-tuned network endures bursts of traffic that can cause packets to be lost at congested network hardware interfaces or dropped by the server. In this case, the excessively long timeout will have a dramatic impact on client performance. With timeo=200, RPC retransmissions "avoid" network congestion by waiting for minutes while the actual traffic peak may have been only a few milliseconds in duration.
Retransmission rate thresholds
There is little agreement among system administrators about acceptable retransmission rate thresholds. Some people claim that any request retransmission indicates a performance problem, while others chose an arbitrary percentage as a "goal." Determining the retransmission rate threshold for your NFS clients depends upon your choice of the timeo mount parameter and your expected response time variations. The equation in Figure 18-1 expresses the expected retransmission rate as a function of the allowable response time variation and the timeo parameter.[2]
Figure 18-1. NFS retransmission threshold
If you allow a response time fluctuation of five milliseconds, or about 20% of a 25 millisecond average response time, and use a 1.1 second (1100 millisecond) timeout period for metadata operations, then your expected retransmission rate is (5/1100) = .45%.
If you increase your timeout value, this equation dictates that you should decrease your retransmission rate threshold. This makes sense: if you make the clients more tolerant of a slow NFS server, they shouldn't be sending as many NFS RPC retransmissions. Similarly, if you want less variation in NFS client performance, and decide to reduce your allowable response time variation, you also need to reduce your retransmission threshold.
NFS over TCP is your friend
You can alternatively use NFS over TCP to ensure that data is not retransmitted excessively. This, of course, requires that both, the client and server support NFS over TCP. At the time of this writing, many NFS implementations already support NFS over TCP. The added TCP functionality comes at a price: TCP is a heavier weight protocol that uses more CPU cycles to perform extra checks per packet. Because of this, LAN environments have traditionally used NFS over UDP. Improvements in hardware, as well as better TCP implementations have narrowed the performance gap between the two.
A Solaris client by default uses NFS Version 3 over TCP. If the server does not support it, then the client automatically falls back to NFS Version 3 over UDP or NFS Version 2 over one of the supported transports. Use the proto=tcp option to force a Solaris client to mount the filesystem using TCP only. In this case, the mount will fail instead of falling back to UDP if the server does not support TCP:
# mount -o proto=tcp wahoo:/export /mnt
Use the tcp option to force a Linux client to mount the filesystem using TCP instead of its default of UDP. Again, if the server does not support TCP, the mount attempt will fail:
# mount -o tcp wahoo:/export /mnt
TCP partitions the payload into segments equivalent to the size of an Ethernet packet. If one of the segments gets lost, NFS