Hi,
On 2016-06-29 17:45, Frank Ch. Eigler wrote:
>
>>>> - in QA 1069 for sample.seconds we get 1 (integer) unlike with
>>>> pmval/pmrep which give typically something like ~0.999-1.001 and for
>>>> sample.milliseconds we get ~1000.002 or such where pmval/pmrep report
>>>> ~1.000.
>>> [...]
>
> This is because the pmfg layer does not presume that second/second is
> the appropriate rate-conversion target for any sort of time rate. It
> will rate-convert automatically via a "/second" denominator only, so
> in the default case the output value would be in "milliseconds/second".
> That explains exactly the 1000 number.
>
> Note that pmval.c lines 221-224 performs the second/second numerator
> conversion heuristic in the application, as does the previous pmrep.py
> (line 1261...). You could bring that logic forward into the new pmfg
> pmrep, or change the testsuite to accept the different-but-correct
> ms/s-scaled numbers.
I think I've sorted out the above but I've got one related question, is
this still expected based on your explanation above or something else?
$ pmval -s 5 -t 2 -z -U qa/archives/20130706 -i sdb disk.dev.avactive
Note: timezone set to local timezone of host "billing02" from archive
metric: disk.dev.avactive
archive: /tmp/pcp/var/lib/pcp/testsuite/archives/20130706
host: billing02
start: Sat Jul 6 00:17:01 2013
end: Sun Jul 7 00:15:43 2013
semantics: cumulative counter (converting to rate)
units: millisec (converting to time utilization)
samples: 5
08:44:01.548 Archive logging suspended
sdb
08:58:23.115 No values available
08:59:23.113 5.590E-02
09:00:23.112 8.877E-02
09:01:23.110 0.1752
09:02:23.108 5.422E-02
$ cat /tmp/testpmfg.py
#!/usr/bin/env python
from pcp import pmapi
import cpmapi as c_api
pmfg = pmapi.fetchgroup(c_api.PM_CONTEXT_ARCHIVE, "qa/archives/20130706")
scale0 = pmfg.extend_item("disk.dev.avactive", mtype=c_api.PM_TYPE_DOUBLE,
scale=None, instance="sdb")
scale1 = pmfg.extend_item("disk.dev.avactive", mtype=c_api.PM_TYPE_DOUBLE,
scale="microsec/s", instance="sdb")
scale2 = pmfg.extend_item("disk.dev.avactive", mtype=c_api.PM_TYPE_DOUBLE,
scale="millisec/s", instance="sdb")
scale3 = pmfg.extend_item("disk.dev.avactive", mtype=c_api.PM_TYPE_DOUBLE,
scale="sec/s", instance="sdb")
pmfg.fetch()
for _ in range(0, 5):
pmfg.fetch()
print ("Value:\t%.6f" % scale0())
print ("Value:\t%.6f" % scale1())
print ("Value:\t%.6f" % scale2())
print ("Value:\t%.6f" % scale3())
$ python3 /tmp/testpmfg.py
Value: 55.901528
Value: 55901.527975
Value: 55.901528
Value: 0.055902
Value: 88.769056
Value: 88769.056034
Value: 88.769056
Value: 0.088769
Value: 175.189301
Value: 175189.301449
Value: 175.189301
Value: 0.175189
Value: 54.218071
Value: 54218.070915
Value: 54.218071
Value: 0.054218
Value: 71.018635
Value: 71018.635067
Value: 71.018635
Value: 0.071019
$
So pmval(1) describes units as "millisec (converting to time utilization)"
which does not correspond to "millisec/s" but to "sec/s" scale value for
pmfg. Since the value disk.dev.avactive shows for how many millisecods
there was active I/O for any device, e.g., 175 looks more expected than
0.175. Is the only confusion on this end or is pmval(1) perhaps a bit
misleading here?
Thanks,
--
Marko Myllynen
|