If it's ls -l rather than just ls, slow user or group lookups can also have
an effect. If the client supports nscd, that should be checked to see that
it's caching user and group info usefully. That is a case of name services
issues, whether the underlying name service is NIS, or LDAP, or anything
other than local files. Any NFS authentication better than AUTH_SYS
(simply trusting that UIDs/GIDs are the same) may have similar problems,
probably as seen by the server.
Google tells me that Linux has an nfsiostat command; the RTT or exe (total
execution of an NFS RPC, including RTT) look like they might be interesting
numbers; find out what's normal, parse it, set thresholds accordingly. It
will probably need to be a client-side script. I've never heard of
nfsiostat before (having worked more on Solaris than Linux), but it sounds
promising.
Ultimately, NFS is difficult to check for performance issues, because
server, network, and as above with ls -l, sometimes other infrastructure
can affect it or appear to affect it.
Tests like a big dd from an NFS mounted file, or a ls of a big directory
(you would need one that was on every client, didn't change, and used the
same server as their home directory) will likely make the problem worse,
adding load to network and server. So something like nfsiostat, that just
reports info already maintained by the kernel, is much safer. Pushing a
client side stress test out to dozens or hundreds of clients could be
easily done once written, but could make the problem MUCH worse. :-)
On Fri, Mar 4, 2016 at 11:17 AM, Paul Jochum <user-679b7591092a@xymon.invalid> wrote:
Hi Xymon List:
Does anyone know of a test script that I can add, that checks if an
NFS mount is performing quickly enough? Basically, I have a few users
complaining that every once in a while, an "ls" of their NFS mounted home
file systems take a long time. I would like a xymon test that could check
for that, in cases where a command (such as an ls of a file system) takes
longer than "x" amount of time, display a warning or error.
Thank you,
Paul