pcp
[Top] [All Lists]

Re: [pcp] Dynamic Proc PMDA metrics

To: Martins Innus <minnus@xxxxxxxxxxx>
Subject: Re: [pcp] Dynamic Proc PMDA metrics
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 17 Nov 2014 23:54:22 -0500 (EST)
Cc: pcp <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <54622BF4.4080806@xxxxxxxxxxx>
References: <545D2CFA.1050600@xxxxxxxxxxx> <1477043892.10880496.1415600819766.JavaMail.zimbra@xxxxxxxxxx> <54622BF4.4080806@xxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: 2C5qwdI8esk63bNYQETGuogn5koxnQ==
Thread-topic: Dynamic Proc PMDA metrics
Hi Martins,

----- Original Message -----
> [...]
> I think I'm ok with fixing everything but this.  I don't understand why
> it is failing. I put some debugging into the indom.c test and all
> queries into the proc pmda, even non-dynamic elements, return bogus
> information from pmLookupName:
> 
> [vagrant@pcptest src]$ ./indom -h unix: -i 1 proc.psinfo.pid
> [...]
> pmLookupName returns successfully (non-error), but all proc queries have
> the domain,cluster,item values of 511,3,0.
> 

OK, this test failure is finally understood.  The root cause was that
qa/src/indom.c makes an unconditional pmLoadNameSpace(3) call, which
puts libpcp into the same mode that pmcd runs it in, where it doesn't
use the distributed namespace calls - instead it answers PMID lookups
itself (so the proc PMDA doesn't get called at all).

This means that pmLookupName calls will return with the dynamic (high)
flag bit set in any metrics from dynamic subtrees, and so subsequent
calls (like the pmLookupDesc on the next line) see an "invalid" PMID.

Anyway, easily fixed - just a QA test update.  With that and a couple
more pending QA test updates we can merge in all the initial work and
the cgroups rework on top of that - arriving shortly.  Lets look into
hotproc QA & get the final hotproc merge done when you're back.

cheers.

--
Nathan

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