pcp
[Top] [All Lists]

Re: [pcp] hotproc rfc

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] hotproc rfc
From: Martins Innus <minnus@xxxxxxxxxxx>
Date: Tue, 14 Oct 2014 16:10:13 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <265957919.64613233.1412813730718.JavaMail.zimbra@xxxxxxxxxx>
References: <536D28B4.6010504@xxxxxxxxxxx> <1139662762.4765310.1399862104653.JavaMail.zimbra@xxxxxxxxxx> <54230FAF.2080201@xxxxxxxxxxx> <905561536.62723741.1412657864635.JavaMail.zimbra@xxxxxxxxxx> <5435926F.6030004@xxxxxxxxxxx> <265957919.64613233.1412813730718.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
Nathan,

On 10/8/14 8:15 PM, Nathan Scott wrote:
Spot on, yes; keeping the existing PMIDs for those proc metrics that
become dynamic and making the hotproc variants just the same (but with
non-conflicting cluster IDs of course).

It seems like the first step would be to convert the existing pmda to
handle dynamic metrics for the appropriate clusters that already exist
before we worry about hotproc?
Yep.  I believe that will work nicely - of course there may be issues
I've not anticipated (lemme know early on, if so), but I'm pretty sure
that will work out well.

I've made some progress on this but wanted to clarify a couple things. This seems a little more involved than I initially thought, unless I'm missing some points. I think we want the metrics to be named as I had in my current implementation:

hotproc.psinfo.pid
and
proc.psinfo.pid

...etc....

but we are still going to have proc metrics that don't map to hotproc variants like:

proc.runq.*
proc.control.*

(Although I suppose a case could be made that someone might want the aggregated runq information for hotproc processes)

And certainly there are hotproc metrics that have no corresponding proc metrics, and the control metrics are different between the two.

But in general, how would root_proc look for a mix of dynamic and static metrics under a single tree? Like this where we would duplicate the dynamic elements for both subtrees?

****************
root {
    cgroup
    proc
    hotproc
}

proc {
    nprocs        PROC:8:99
    psinfo         PROC:*:*
    memory      PROC:*:*
    runq
    id               PROC:*:*
    io               PROC:*:*
    schedstat   PROC:*:*
    fd               PROC:*:*
    control
}

hotproc {
    nprocs        PROC:52:99
    psinfo         PROC:*:*
    memory      PROC:*:*
    id               PROC:*:*
    io               PROC:*:*
    schedstat   PROC:*:*
    fd              PROC:*:*
    control
    total
    predicate
}

******************

If this is the case, how do the calls to "pmdaDynamicPMNS" work? We would need at least 2, correct:?


pmdaDynamicPMNS("proc",.....
pmdaDynamicPMNS("hotproc",.....

Or would we need one for each proc.foo entity since we are mixing dynamic and static items in a tree?

My confusion mostly stems from the fact that I haven't yet figured out if there is a "right way" to do this mixing. i.e. do I just skip over any static metrics in the "refresh_*" calls?

Or should everything under proc be dynamic?  Thus, I would just do:

***********************
root {
    cgroup
    proc        PROC:*:*
    hotproc   PROC:*:*
}
***********************

But then, again, I need some way of handling static metrics that don't overlap.


The second observation is that namespace grouping are not 1:1 wrt cluster groupings. For example, proc.psinfo contains metrics from 4 different clusters. From my reading of existing code, I don't think this will be a problem, but just wanted to check.


Finally, I looked through various pmdas and some (mmv and sample) handle dynamic metrics in a more direct way, without the infrastructure provided by pmdaDynamicPMNS adding to my confusion on the right way to do this.

Thanks for any prodding in the right direction.

Martins

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