[hsfzxjy]

And with strace -p pid you can somewhat "spy" on what a process is doing.

[T3OU-736]

There us a hugely non-trivial (on the order of 100x) slowdown in code running when strace does its thing.

Brendan Gregg's work in the field of performance analysis (eBPF to the rescue) is quite useful in this regard, though not without tradeoffs (AFAIK: need compiler tools on the system to compile eBPF code).

Using `perf` may be a decent middle ground.

[gregw2]

This. (Combine with sudo too!)

Now if I could just track NFS client traffic on a client associated with a PID (without having NFS server access). All I can get is all-PID/client-kernel data info vi nfsstat, nothing tying to a PID, filename, directory or inode to tell me which PID is causing all the NFS traffic!

[fragmede]

    iotop?

[gregw2]

Tried it, I think the problem is the nfs io comes from the kernel and is not tied to a PID?

[jasonhansel]

`lsof -p pid` can also be a good way of determining what a process is doing at a given point in time, if you're just trying to figure out what files it has open.