3

I have an NFS mount where the server is on the same subnet as the client. When I time touch testempty from the client, I get:

touch testempty  0.00s user 0.00s system 0% cpu 1.325 total

The time follows an bizarre pattern - Most of the time it's just over one second, but approximately once per minute it spikes to around 1.3. See this graph, compiled from time it takes to touch a nonexistent file, once every ten seconds:

graph of latency

When I rm testempty then time touch testempty from the server, I get:

touch testempty  0.00s user 0.00s system 29% cpu 0.005 total

So disk isn't the problem. Ping shows sub-200us latency, so network isn't the problem either. I've found that this still happens when the server mounts its own share.

Here is my /etc/exports:

/data           192.168.0.0/16(rw,no_subtree_check,async,no_root_squash,insecure,sec=sys,fsid=0)
/data/dba_work  192.168.0.0/16(rw,no_subtree_check,async,no_root_squash,insecure,sec=sys,fsid=1)

Any idea what's causing this?

Server is running CentOS 7. Have tried multiple different Linux clients, including the server itself.

Edit: Here's another graph: 30 minutes, taken at two second intervals:

graph of latency over 30 minutes, taken every two seconds

6
  • You wrote "Have tried multiple different Linux clients, including the server itself" - what did you mean by the last part? Did you NFS-mount the share on the server (localhost) and saw the same latency or did you test on the server w/o NFS involved and also saw the latency? The latter would rule out any NFS or network issues and you can now focus on local debugging of your performance issue. Also, did it ever work better, with earlier kernels / systems?
    – ckujau
    Commented Oct 9, 2018 at 4:32
  • @ckujau The former. And unfortunately no clue because this is my initial setup I'm trying to get working. Commented Oct 9, 2018 at 4:48
  • Are you using the optional idmapd or rpc.idmapd demon, or rpc.gssd?
    – meuh
    Commented Oct 9, 2018 at 15:10
  • @meuh rpc.gssd. Commented Oct 9, 2018 at 15:45
  • @meuh I think I see where you're going with this, and I think you're likely right. This was originally going to be krb5 security, but I couldn't get it to work on all systems (see my question history). But if that's the cause, then why, when the security is sys, would it be querying Kerberos? Commented Oct 9, 2018 at 15:47

0

You must log in to answer this question.

Browse other questions tagged .