On Tue, 31 Oct 2000, Mark Goodwin wrote:
>
> [helpful stuff explaining Michal's "problem" deleted]
>
> In addition, if you have PM_SEM_INSTANT metrics that should not be
> interpolated during archive replay, (e.g. perhaps apache.busy_servers because
> it does not make sense to have 0.6 servers) then you should change their
> semantics to PM_SEM_DISCRETE instead. This tells pmFetch not to interpolate
> values between samples. See the man page for pmLookupDesc(3) for details.
This part is not quite correct.
For archives, pmSetMode is used to establish a desired time (the when
argument) within the span of the archive and the mode and delta
arguments define what happens on subsequent pmFetches according to the
following semantics:
PM_MODE_FORW or PM_MODE_BACK
Ignore delta. Go to the next record in the archive that
contains at least one of the requested metrics (as described by
Mark).
PM_MODE_INTERP
March the time by delta at each pmFetch (negative delta means
scan the archive backwards). When fetching use sensible
heuristics to compute a reasonable value for all requested
metrics at the desired time.
The semantics of each requested metrics influences the
"sensible heuristics" as follows:
PM_SEM_COUNTER
Linear interpolation between the two observations that
most closely bound the desired time.
PM_SEM_DISCRETE
Use the closest earlier value.
PM_SEM_INSTANT
Same as PM_SEM_DISCRETE, except there must be two
observations that bound the desired time.
In practise, PM_SEM_DISCRETE is used for metrics that are most unlikely
to change during the archive, e.g. hinv.ncpu, while PM_SEM_INSTANT is
used for metrics where the value is a snapshot of some underlying and
changing variable, e.g. filesys.free.
So apache.busy_servers should be PM_SEM_INSTANT and the value when
using PM_MODE_INTERP will be integral and akin to the "most recent
observed value" relative to the desired pmFetch time.
|