On 07/05/15 20:29, Marko Myllynen wrote:
...
once I understand this a bit better myself I'll send a patch to add a
note about derived metrics in the PCP Quick Guide. I did search for
"calculate" and "derive" from the books but didn't find anything about
derived metrics from there.
That would be good. Derived metrics happened much later than the last
updates to the books from SGI, so it is not surprising there is no
mention there.
...
And I'm not sure why the /100 is required, could you please explain
that part?
kernel.all.uptime is in seconds but hotproc.psinfo.start_time is in
jiffies and although jiffies-to-seconds is not necessarily a trivial
operation [1], /100 seemed to provide "close enough" results during my
tests. ...
Be careful. We (in PCPland) try very hard to avoid platform-variant and
decade-variant units of measure ... blocks and hz and jiffies are all in
this bag.
So no matter what units the base instrumentation is in, the PMDA is
responsible for translating it to something useful and invariant ...
like seconds in this case.
$ pminfo -d hotproc.psinfo.start_time kernel.all.uptime
hotproc.psinfo.start_time
Data Type: 32-bit unsigned int InDom: 3.39 0xc00027
Semantics: discrete Units: sec
kernel.all.uptime
Data Type: 32-bit unsigned int InDom: PM_INDOM_NULL 0xffffffff
Semantics: instant Units: sec
But unfortunately in this case the PMDA implementor says the metrics are
seconds, but they are not (see the example below) ... this is a BUG ..
the PMDA should return hotproc.psinfo.start_time either /100 and call it
seconds or *10 and call it msec (and increase it to 64-bits in this case).
# pminfo -f proc.psinfo.start_time | sed -e 's/.* value //' | sort -nr |
head -2 ; pminfo -f kernel.all.uptime
9086825
9086825
kernel.all.uptime
value 90868
If this was fixed you would not need the /100.
...
Now, if we're in the business of adding more stuff to your RFE queue..
;-) Would you see it feasible to use derived metrics to derive metrics?
For example, in your example you had:
mytest.divisor = hotproc.psinfo.start_time - kernel.all.uptime
mytest.marko = hotproc.psinfo.rss / (hotproc.psinfo.start_time -
kernel.all.uptime)
It would be nice to be able to write this as:
mytest.divisor = hotproc.psinfo.start_time - kernel.all.uptime
mytest.marko = hotproc.psinfo.rss / mytest.divisor
I don't think nested definitions are going to happen ... the code behind
this is already pretty complex ... but I could entertain a pmie-style
macro definition and substitution that would achieve the same effect.
|