How to Troubleshoot NFS Latency With nfsiostat

Updated: 29 September 2026 · Applies to: nfs-utils 2.5 to 2.8 on AlmaLinux and Rocky Linux 9 and 10, RHEL 9 and 10; nfs-common on Ubuntu 24.04 and 26.04 and Debian 13

When an NFS share feels slow, the first question is where the time goes: the network, the NFS server, or waiting inside the client. nfsiostat answers that per mount point, from the counters the kernel keeps in /proc/self/mountstats. It works like iostat, but for NFS mounts on the client.

Install and run

nfsiostat comes with the NFS client tools: the nfs-utils package on AlmaLinux, Rocky Linux and RHEL, and nfs-common on Ubuntu and Debian.

nfsiostat 5 3              # three reports, 5 seconds apart, for all NFS mounts
nfsiostat 5 /mnt/data      # continuous reports for one mount point
nfsiostat -a 5 1           # attribute cache statistics
nfsiostat -d 5 1           # directory operations (lookup, readdir)

The first report covers the whole time since the share was mounted. Watch the following ones, which cover each interval, while the slow work is running.

Read the output

For each mount you get a total line (ops/s and rpc bklog) and then one line for reads and one for writes with these columns:

• ops/s: requests per second. The total includes all NFS operations (lookups, attribute checks and so on), not only reads and writes.
• kB/s and kB/op: throughput and average request size. Small kB/op for large files can point to small rsize/wsize mount options or an application writing in small pieces.
• retrans: retransmitted requests. Anything above zero means requests were lost or answered too late: look at the network (packet loss, MTU problems) or an overloaded server.
• avg RTT (ms): time from sending a request to receiving the answer. It covers the network and the server's own work.
• avg exe (ms): total time of a request inside the client, including RTT and waiting in the client's queue.
• avg queue (ms): time requests waited in the client before they were sent.
• errors: requests that returned an error (shown when the kernel reports it).

rpc bklog is the length of the client's queue of requests waiting to be sent. A value that stays high means the client produces requests faster than the connection or server can take them.

Where is the delay?

• High RTT, low queue time: the time is spent on the network or on the NFS server. Check ping times and packet loss to the server, then the server's disk and CPU load.
• Exe much higher than RTT, high queue time or bklog: requests wait on the client. Check the client's CPU load and the number of parallel NFS connections; the nconnect=N mount option (for example nconnect=4) can spread the load over several TCP connections.
• Retransmissions: fix the network first; the other numbers are unreliable while requests are lost.

For a quick view of all NFS operations on the client, nfsstat -c shows the call counts per operation, and mountstats /mnt/data gives the full detail behind nfsiostat.

Official documentation: nfsiostat manual and nfs(5) mount options.