The nfsstat -c command

Edit online

The NFS client displays the number of NFS calls sent and rejected, as well as the number of times a client handle was received, clgets, and a count of the various kinds of calls and their respective percentages.

The following example shows the nfsstat command output specified for clients using the -c option:

# nfsstat -c

Client rpc:
Connection oriented
calls     badcalls  badxids  timeouts  newcreds badverfs  timers
0          0          0          0          0          0          0
nomem     cantconn interrupts
0          0          0
Connectionless
calls     badcalls retrans   badxids   timeouts newcreds  badverfs
6553       0          0          0          0          0          0
timers    nomem     cantsend
0          0          0


Client nfs:
calls      badcalls   clgets     cltoomany
6541       0          0          0
Version 2: (6541 calls)
null       getattr    setattr    root       lookup     readlink   read
0 0%       590 9%     414 6%     0 0%       2308 35%   0 0%       0 0%
wrcache    write      create     remove     rename     link       symlink
0 0%       2482 37%   276 4%     277 4%     147 2%     0 0%       0 0%
mkdir      rmdir      readdir    statfs
6 0%       6 0%       30 0%      5 0%
Version 3: (0 calls)
null       getattr    setattr    lookup     access     readlink   read
0 0%       0 0%       0 0%       0 0%       0 0%       0 0%       0 0%
write      create     mkdir      symlink    mknod      remove     rmdir
0 0%       0 0%       0 0%       0 0%       0 0%       0 0%       0 0%
rename     link       readdir    readdir+   fsstat     fsinfo     pathconf
0 0%       0 0%       0 0%       0 0%       0 0%       0 0%       0 0%
commit
0 0%

RPC output for the client, -c, is as follows:

calls: Total number of RPC calls made to NFS
badcalls: Total number of calls rejected by the RPC layer
retrans: Number of times a call had to be retransmitted due to a timeout while waiting for a reply from the server. This is applicable only to RPC over connectionless transports
badxid: Number of times a reply from a server was received that did not correspond to any outstanding call. This means the server is taking too long to reply
timeouts: Number of times a call timed-out while waiting for a reply from the server
newcreds: Number of times authentication information had to be refreshed.
badverfs: Number of times a call failed due to a bad verifier in the response.
timers: Number of times the calculated timeout value was greater than or equal to the minimum specified timeout value for a call.
nomem: Number of times a call failed due to a failure to allocate memory.
cantconn: Number of times a call failed due to a failure to make a connection to the server.
interrupts: Number of times a call was interrupted by a signal before completing.
cantsend: Number of times a send failed due to a failure to make a connection to the client.

The output also displays a count of the various kinds of calls and their respective percentages.

For performance monitoring, the nfsstat -c command provides information on whether the network is dropping UDP packets. A network may drop a packet if it cannot handle it. Dropped packets can be the result of the response time of the network hardware or software or an overloaded CPU on the server. Dropped packets are not actually lost, because a replacement request is issued for them.

The retrans column in the RPC section displays the number of times requests were retransmitted due to a timeout in waiting for a response. This situation is related to dropped UDP packets. If the retrans value consistently exceeds five percent of the total calls in column one, it indicates a problem with the server keeping up with demand. Use the vmstat and iostat commands on the server machine to check the load.

A high badxid count implies that requests are reaching the various NFS servers, but the servers are too loaded to send replies before the client's RPC calls time out and are retransmitted. The badxid value is incremented each time a duplicate reply is received for a transmitted request. An RPC request retains its XID value through all transmission cycles. Excessive retransmissions place an additional strain on the server, further degrading response time. If thebadxid value and the number of timeouts are greater than five percent of the total calls, increase the timeo parameter of the NFS-mount options by using the smitty chnfsmnt command. If the badxid value is 0, but the retrans value and number of timeouts are sizable, attempt to decrease the NFS buffer size using the rsize and wsize options of the mount command.

If the number of retransmits and timeouts are close to the same value, it is certain that packets are being dropped. See Dropped packets for further discussion.

In some instances, an application or user experiences poor performance, yet examination of the nfsstat -c command output indicates no or very few timeouts and retransmits. This means that the client is receiving responses from the server as fast as it is asking for them. The first thing to check is that there is an appropriate number of biod daemons running on the client machine. This can also be observed when an application is doing remote file locking. When remote file locks are set on a file served over NFS, the client goes into a fully synchronous mode of operation that will turn off all data and attribute caching for the file. The result is very slow performance and is, unfortunately, normal. You can identify locking packets in ipreport output by looking for NLM requests.