https://bugzilla.redhat.com/show_bug.cgi?id=1269921
Ken McDonell <kenj@xxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(kenj@xxxxxxxxxxx) |
--- Comment #4 from Ken McDonell <kenj@xxxxxxxxxxx> ---
pmlogger has always been thus ... or rather ever since it was changed to use
__pmAFregister() to control the scheduling of fetches and the delay comes from
the semantics of __pmAFregister() and is documented in the man page there.
And I think pmlogger was changed to use __pmAFregister() in 2004 or thereabouts
(I can find one circa 2004 archive that definitely does not have this
behaviour). So this is definitely not a recent change in behaviour, and the
first time that anyone has noticed in at least a decade.
In pmlogger there was no attempt to stagger start and avoid a thundering herd
... pmie does this but pmlogger simply delays the thundering herd for one delta
time period! So no tricky performance justification for the current behaviour.
Nathan's patch works for the pmcollectl case, but it is probably appropriate to
consider if pmlogger should be changed so that all users of pmlogger would see
an initial sample soon after the configuration file had been parsed and then
the current behaviour would take over, and the pmcollectl patch would not be
required.
Biggest fallout risk would be in QA I think. I've looked at the pmlogger code
and the change there is low risk (and would be the similar to Nathan's
pmcollectl patch, because the alternative of changing the __pmAFregister()
semantics is just too scary).
--
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=PSNGJU400c&a=cc_unsubscribe
|