On Tue, 18 Oct 2011 15:08:28 -0500, Ben Myers wrote:
Max> - call details.
Max> It's easy to create a ueber-array of all options and just list
Max> them all but it's probably not the most convinient for the user. I was
Max> thinking about mapping some of the options so that different NFS
Max> versions can have similar names.
bpm> I'm not sure I understand. Can you give an example?
bpm> Maybe something like:
bpm> nfs.reqs.getattr.count
bpm> vs
bpm> nfs4.reqs.getattr.count
No, I think that having specific versions in there would be less
useful: ideally it shouldn't matter if one uses v4 or v2. On
the other hand it's probably makes no sense to compare v4 getattrs
with v3 ones in the same observation, so having separate versions
isn't so bad. I'll ask NFSy people around for their opinions.
I'm also not sure if I prefer nfsclient.ops.getattr.count or
nfsclient.ops.count.getattr. First makes it easier to get information
about getattr but second is more useful in general - I'm more often
intersted in the overall mix of ops.
But I'd definitely like to see opname in lower case.
Max> - U32 for counts is probably a bit low - any particular reason for
Max> not going U64?
>>
Nathan> What type is it in the kernel? (need to match - there's also helper
Nathan> pmda_long and pmda_ulong types if thats what the kernel is using)
bpm> Exactly. I used types to match those in the kernel. Hopefully I didn't
bpm> overlook any.
Kernel is using ulong for the ops, transmissions and timeouts
counters.
Nathan, how does pmda_ulong works? Is it smart enough to figure out
difference between longs on 32 vs 64 bit platforms?
Max> - per-transport metrics - once again would be nice to have some
Max> commonality.
bpm> Hmmm. Again you lost me.
Drop tcp - all three (udp, rdma, tcp) export sends, receives, bad_xid,
bind, req_u and backlog_u, tcp has some extras which UDP does not have
and rdma adds a bunch more. Between udp and tcp it's going to cover
99.(9)% of the users. I'd just have things like
nfsclient.xprt.sends
nfsclient.xprt.connect_time
and then return no values for UDP mounts.
Max> - instance domain - any particular reason you've used server 'exports'
Max> and not local mount points?
bpm> Yeah, maybe you're right. My impression had been that separate nfs
bpm> client superblocks can share the same counters and transports if they're
bpm> using the same server... so that's why I had an instance per server
bpm> export.
FWIW, it's already causing problems: I've got 3 mounts, all from the
same server/export but using different protocols and NFS versions. I'm
getting 2 instances and wrong values, e.g.:
[root@renata nfsclient]# pminfo -f nfsclient.mtpt
nfsclient.mtpt
inst [1 or "localhost:/var/tmp"] value "/mnt/tmp3"
inst [0 or "localhost:/var/tmp"] value "/mnt/tmp3"
Max> BTW, they're not really exports - one can
Max> mount any directory (or even a file) within exported hierarchy.
bpm> Sometimes I forget that too... force of habit. Whether a separate
bpm> instance is needed should depend upon whether the counters are shared by
bpm> the nfs mounts in that situation. That's something I need to look into.
Discovering that nfs_server is shared between mounts would be
.... "interesting": it's not only shared across multiple mounts from
the same export but also across exports from the same server. This
really screws up statistics by double-counting, so really what you're
going to get is some information about rpc_xprt thingy except you
cannot really identify them in any other way but by using server
address, client address, source port, destination port and transport.
Really good instance names: tcp,bozo:907-gonzo:2049. Not!
Max> I'll give it a spin on a Linux box to see how it works.
I've couldn't do the normal ./Install procedure for the pmda for some
reason: first I had no pmns (pmns.perl was created but wasn't picked
up by the installer). I've fakes it with just a normal pmns and then
pmda was not executable. It's a first time I've tried to use perly
pmda and I must say the experience was traumatic. Nathan, did I do
something wrong here?
bpm> THanks! It might be a little while before I can work on it again... but
bpm> I'll try to make use of the pointers you've provided.
It would be nice if we can get the namespace and instances agreed
before this thing escapes. For example, you seems to follow unix
tradition of saving up vowels in mtpt and then go overboard with
normalwrittenbytes. I'd rather have nfsclient.mountpoint and
nfsclient.bytes.read.direct.
I think it could be useful to get this pmda into the official tree but
not include it into the packages just yet.
max
|