150 seconds is, indeed, way to long. I've never seen anything like this
before, but Windows clients aren't well tested, since none of the
developers have access to them. Some things you can do:
1. Turn on FULL_DEBUG logging. This will slow down normal operations,
but log lines all have timestamps, so you can scan through the relevant
OPs to see where there's gaps in the log messages. This can narrow down
the code locations that are causing the slowdown.
2. If logging isn't possible, you can turn on LTTng tracing. This is
much lower latency, and can log at scale, but is more difficult to set
up, and has fewer tracepoints. However, I've found it useful in the
past to track down timing issue, especially ones that only reproduce
under load. You can, of course, add new tracepoints if you need to
further narrow down the issue.
Daniel
On 1/13/20 7:37 AM, QR wrote:
In Windows nfs client, nfs_rpc_process_request(lookup/readdir etc)
sometimes takes more than 150 seconds(v3_full).
I think this is weird, because 150 seconds too long.
Is anyone know what's going on during the period? Thanks in advance.
Ganesha server info
ganesha version: V2.7.6
FSAL : In house
nfs client info
nfs version : nfs v3
client info : Windows server 2012
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org