NFS Linux Client RPCs Test

This test monitors the NFS requests sent by clients, reports the total number of such requests, and reveals how many of these requests were retransmitted to the server. Retransmitted requests, if allowed to grow in number, can prove to be a serious bottleneck to the performance of the NFS. That way, this test, with its ability to promptly alert administrators to spikes in the number of retransmitted requests, is very useful.

Target of the test : NFS on Linux Client

Agent deploying the test : An internal agent

Outputs of the test : One set of results for every remotely mounted NFS.

Configurable parameters for the test
Parameter Description

Test period

How often should the test be executed


The host for which the test is to be configured.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Number of RPC calls

Indicates the total number of RPC calls received from clients   to the NFS server  during  the last measurement period.


This is a good indicator of the workload on the server.

Number of retransmitted requests

Indicates the total number of retransmitted RPC calls from clients during the last measurement period.


Requests can be retransmitted due to dropped packets, socket buffer overflows, general server congestion, timeouts, etc. A high value for No of retransmitted requests and Percentage of retransmitted requests is hence, a cause for concern.

One of the common reasons for request retransmission is the lack of sufficient number of NFS kernel threads on the server for processing client requests. The default number of threads for rpc.nfsd to start is typically eight threads. To tell rpc.nfsd to use more kernel threads, the number of threads must be passed as an argument to it. Typically, most distributions will have a file such as /etc/sysconfig/nfs to configure this. In the file, increase this number — perhaps to 16 — on a moderately busy server, or increase up to 32 or 64 on a more heavily used system. Re-evaluate using nfsstat to determine whether or not the number of kernel threads is sufficient; if the retrans setting is 0 then it is enough; but, if the client still needs to retransmit, increase the number of threads further.

Timeouts can also cause requests to be retransmitted. Two mount command options, timeo and retrans, control the behavior of UDP requests when encountering client timeouts due to dropped packets, network congestion, and so forth. The -o timeo option allows designation of the length of time, in tenths of seconds, that the client will wait until it decides it will not get a reply from the server, and must try to send the request again. The default value is 7 tenths of a second. The -o retrans option allows designation of the number of timeouts allowed before the client gives up, and displays the Server not responding message. The default value is 3 attempts. Once the client displays this message, it will continue to try to send the request, but only once before displaying the error message if another timeout occurs.

Percentage of retransmitted requests

Indicates the retransmitted RPC calls from the clients  during the last measurement period.


When the client reestablishes contact, it will fall back to using the correct retrans value, and will display the Server OK message. If you are already encountering excessive retransmission, If you are already encountering excessive retransmissions (see the output of the nfsstat command), or want to increase the block transfer size without encountering timeouts and retransmissions, you may want to adjust these values.

Number of times authentication information had to be refreshed

Indicates the total number  of times authentication information  had  to be refreshed  on clients during  the last measure period.