Hello,
The message you are receiving simply means that the NFS server is not responding due to a timeout. The reasons vary but you can do a few things to determine where to start diagnosing the problem. NFS performance t-shooting can become a time consuming event, I've referenced a few documents below to help you out.
To start, the NFSD daemons are server side only and don't affect the NFS clients. If you increase the NFSD's do so on the NFS server. The Automount options -t 3600 tell the Automounter how often to check to see if the mount point is active so that it can either umount it or reset its timer. Its a good idea to set this higher than the default of 5 minutes but it will not solve the timeout messages you are receiving, it may solve the frequency at which you see them but thats not going to resolve your root problem.
What you need to do is figure out if your problem is with the NFS server, the Network or the NFS client.
For two "Shorter Guides" to NFS Performance issues reference these ITRC documents, NETUXKBRC00006283 & KBAN00000261
For a very detailed White paper on NFS peformance follow this link.
http://www.docs.hp.com/hpux/onlinedocs/1435/NFSPerformanceTuninginHP-UX11.0and11iSystems.pdfSome Things to consider:
TCP vs. UDP?
Are you using the Legacy Automounter or Autofs?
For TCP you need the Autofs client and not the legacy Automounter, you can tell which you are using by checking the output of ps -ef|grep auto, if you have a autofs_proc process then you are using autofs if not you are using the Legacy Automounter.
By default a 11.X server will attempt TCP and fall back to UDP if TCP is not available. The general idea is to use UDP on localized / clean networks and to use TCP between systems that traverse multiple devices. You can control which protocol to use via tha mount option proto= see man mount_nfs for details. If your using the Legacy Automounter UDP is your only choice, if you use the Autofs program you can specify TCP.
From your client you can start to narrow down your issue with the nfsstat command.
( check those docs above for more details on the output of the nfsstat commands )
nfsstat -c
Client rpc:
calls badcalls retrans badxid timeout wait newcred
1081 0 0 10 8 10 0
Client nfs:
calls badcalls nclget nclsleep
1074 0 1074 0
null getattr setattr root lookup readlink read
0 0% 240 22% 0 0% 0 0% 636 59% 0 0% 34 3%
wrcache write create remove rename link symlink
0 0% 0 0% 0 0% 1 0% 0 0% 0 0% 0 0%
mkdir rmdir readdir statfs
0 0% 0 0% 160 14% 3 0%
For the above stats the items of note are the number of retransmissions, timeouts and badxid's. Where,
calls The total number of RPC calls made.
badcalls The total number of calls rejected by the RPC layer.
retrans The number of times a call had to be retransmitted due to a timeout while waiting for a reply from the server.
badxid The number of times a reply from a server was received which did not correspond to any outstanding call.
timeout The number of times a call timed out while waiting for a reply from the server.
wait The number of times a call had to wait because no client handle was available.
newcred The number of times authentication information had to be refreshed.
Since the number of badxid's received is roughly the same as the timeouts, this indicates that the NFS server involved is simply late or slow in responding, perhaps due to load. The late reply will be seen as a transaction ID which is no longer valid. The read/write sizes and timeout values can be altered in the mount options to accomidate this on a per server basis.
If the retransmit/timeout rates are an order of magnitude larger than the badxid count, it would indicate that the replies were simply dropped/lost somewhere in transit to or from the server. To isolate where in the path the packets are being dropped, a network trace using the client (nettl tracing in HP's case), server, or external analyzer is needed. Some switches/routers keep statistics on packet loss on a per port basis as well.
Also don't discount softare levels, the ONC ( NFS ) patches should be checked to see an update is appropriate.
The latest NFS patches are:
11.11 PHNE_29211 s700_800 11.11 ONC/NFS General Release/Performance Patch
11.0 PHNE_28982 s700_800 11.00 ONC/NFS General Release/Performance Patch
Hope this helps,
Todd
