wcohen wrote:
> Nesting of predicates
> [...] [ideally ... ] subtree many levels down is only examined if
> the nodes above it also have high values. Thus, the levels above
> predicate the lower levels. PMIE seems to be oriented to doing a
> flat analysis of the machine metric. [...]
Depending on how deep the tree goes, there may or may not be serious
savings to be had. It the optimization were worthwhile, a construct
similar to [1] could work within pmie too.
[1] http://oss.sgi.com/pipermail/pcp/2015-July/007884.html
> Better parametrization of thresholds
> In the PMIE documentation magic numbers are used (for example 2,000
> context switches per second) as thresholds. [...] what happens in
> a heterogeneous enviroment where some machines have spinning drives
> and others have SSD drives? [...]
Yeah, either parametrize the pmie scripts better, or have separate
pmie scripts (and provide machinery to conveniently choose between
them), or make the scripts inherently adaptive (analytics). The new
pmlogger %shell widget could accomplish this, especially if it were
parametrized with the target host/context (so it could do its own
hinv etc. enquiries or whatnot).
> Analysis over aribitrary intervals
> [...]
> For example allow analysis over the lifetime of a cron job is
> running or between the start and end of some phase of a program.
PCP events permit representation of time intervals, but are not
widely exploited. pmie rules can be conditional on instances
(like matching on process names for the proc.* metrics).
Anyway, PMIE could be a useful tool in identifying the patterns for
such analysis. While waiting for above limitations to be overcome, we
can still rely on the human vision system. We can detect patterns
based on well-organized graphical renderings of data, plus a guided
traversal between related or drill-down views.
- FChE
|