https://bugzilla.redhat.com/show_bug.cgi?id=1269921
Nathan Scott <nathans@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #2 from Nathan Scott <nathans@xxxxxxxxxx> ---
Hmm, this is an interesting one. Lukas is on the right path, except the
"problem" is actually in pmlogger! Turns out (news to me) that pmlogger
interprets the 'log every N interval' to be starting at the time the first
interval elapsed, and not starting at the time pmlogger starts.
IOW, pmlogger (which is doing the recording here, below the pmRecordControl
API) does not issue a fetch until the first interval passes, except for the
pmcd.pmlogger.* control metrics which it always fetches & logs immediately.
So, if we look at the timestamps associated with the archives being recorded
here ("pmdumplog -a" is the best tool for this, it doesn't interpolate or rate
convert or anything like that, which the other tools usually will), we see no
"kernel.all.nprocs" value until the first interval passes, then two, with the
last being right at the pmlogger termination time.
It may be this is by-design from pmloggers POV (so that we do not issue a
potentially large number of fetches all at once, for every fetch group - not
sure) - Ken?
We can work around this though if that's the case - from some experimentation,
if pmcollectl creates a log-once fetch group in addition to the 'log every N
seconds' group for pmlogger, that gives the anticipated behaviour.
OTOH, maybe pmlogger behaviour is not as desired - will wait to hear from Ken.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=ja6EquWm3Y&a=cc_unsubscribe
|