pcp
[Top] [All Lists]

Re: [pcp] nfsclient pmda

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] nfsclient pmda
From: Martins Innus <minnus@xxxxxxxxxxx>
Date: Mon, 03 Mar 2014 15:59:13 -0500
Cc: pcp@xxxxxxxxxxx, Ben Myers <bpm@xxxxxxx>, Max Matveev <makc@xxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5314EA02.9060906@xxxxxxxxxxx>
References: <52F3A564.4060007@xxxxxxxxxxx> <1469416634.21700255.1391728771761.JavaMail.root@xxxxxxxxxx> <D2E9833E-1D7F-41F5-97C4-4438712E3BF2@xxxxxxxxxxx> <742242243.21951337.1391769716120.JavaMail.root@xxxxxxxxxx> <530D0904.2090804@xxxxxxxxxxx> <1661706871.16390260.1393364346293.JavaMail.zimbra@xxxxxxxxxx> <5314EA02.9060906@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
Sorry if this duplicates, I got a rejection message due to the attachments. Trying again with a zip file.

Martins

On 3/3/14 3:45 PM, Martins Innus wrote:
Nathan,

Have a look at the src/pmdas/simple/pmdasimple.perl code - this PMDA has
both styles. The $color_indom uses the array style and $now_indom uses a
hash (under the covers, in PCP::PMDA, the latter translates to pmdaCache
use).

OK. I think I got this working with a hash. I can't figure out how to get confirmation that it actually is using pmdaCache though.

I think I addressed most of the issues raised previously, but wanted to get some feedback on a couple of items before finishing up.

1. Types should now match kernel types, let me know if you think I missed any.

2. I dropped the tcp identifier under xprt, and just created a union of all the possible types across tcp, udp and rdma. I have only tested tcp. I hope to test udp shortly. I don't think I'll be able to test rdma in the near future as we don't use it in production currently.

3. Used mountpoints in the instance domain. I think this is the best we can do. Its what mountstats itself is using to partition the data and you'd have the same issue of double (or triple, etc) counting the data if you looked at /proc/self/mounstats vs this pmda. I'm up for other suggestions if there are any.

4. There didn't seem to be any consensus on nfsclient.ops.getattr.count vs. nfsclient.opts.count.getattr so I left it. Let me know if it should be changed.

5. My biggest question is what to do about the nfs3, nfs4 vs nfs4.1 per-op statistics. See the attached pdf, one column per version, matching types aligned. There are 22, 47 and 53 stats for v3, v4 and v4.1 respectively. Should it be treated the same as the tcp/udp/rdma case and just zero out the ones that dont apply? I haven't implemented this yet, but if that's what you think should be done, it should be pretty straightforward to do.

6. Finally, how much of the opts, caps, and sec fields should be parsed out? I grabbed a couple for now that are obviously useful, but can do them all if that's the way to go. Again, similar issue to the previous point with respect to options that pertain to nfs versions.

Thanks for any feedback.

Martins

Attachment: nfsclient
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>