-
-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
denki: derived metrics assigning power draw to individual processes #1827
base: main
Are you sure you want to change the base?
Conversation
1463bff
to
94627bc
Compare
Denki (power) derived metrics, based on discussion with Christian Horn over the last few weeks. These derived metrics use RAPL hardware metrics to assign power usage to processes based on the processor and memory power draw metrics.
94627bc
to
26f5681
Compare
Hm.. with a build of PCP as of today (with commit 1d3a251 as HEAD), the syntax of [core] as referring to an instance still seems not recognized:
|
The latest commit fixes the libpcp issues around derived metrics, it does not fix the denki derived metric issue. So far I've been concentrating on the "cpu" one, and I've run into these issues:
so may be it is the names that are reversed. I am expecting "raw" to be the raw values from the source, and "rate" to be somehow modified by the PMDA before export. If I use the "rate" metric as though it was a counter, then the closest I can get to the desired expression for the per-process power (based on pro-rated CPU usage) is:
I think we need to sort out the data semantics issues with the PMDA first, then cycle back to the "core" vs "package-0" vs "???" issue. |
Hi Ken,
Is this described? For example 'apropos instantaneous' is not giving me hits.
As a result, the rate can also not directly be computed on the first line of output and we get N/A. Which terms should be changed?
Until now, we did not really pay deeper attention to the components of the package-X. I can not remember having hit an x86 system without core though. Capturing a 'find /sys' from the system might be interesting, in next step I would then ask for tar archive with more details, in the style of what qa/denki/*tgz contain.
Yes, consistant with the concept I used for rapl. denki.bat.energy_now_raw is directly read (but a gauge from kernels view), denki.bat.energy_now_rate is computed by pmda-denki from that _raw. denki.bat.power_now and denki.bat.capacity are raw values read from the kernel, these are gauges and go up/down.
That could make sense, it would reduce the amount of data to be stored as 'direct metrics'. I should search for good examples where we do this. |
@christianhorn Let's move this discussion to email. |
Denki (power) derived metrics, based on discussion with Christian Horn over the last few weeks.
These derived metrics use RAPL hardware metrics to assign power usage to processes based on the processor and memory power draw metrics.