[Top] [All Lists]

Re: [pcp] suitability of PCP for event tracing

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] suitability of PCP for event tracing
From: Max Matveev <makc@xxxxxxxxx>
Date: Mon, 13 Sep 2010 23:29:14 +1000
Cc: "Frank Ch. Eigler" <fche@xxxxxxxxxx>, systemtap@xxxxxxxxxxxxxxxxxx, pcp@xxxxxxxxxxx
In-reply-to: <4C8D0317.6000807@xxxxxxxxxxxxxxxx>
References: <20100827153906.GD3185@xxxxxxxxxx> <4C7A7DFE.2040606@xxxxxxxxxxxxxxxx> <20100831194941.GC5762@xxxxxxxxxx> <4C8D0317.6000807@xxxxxxxxxxxxxxxx>
On Mon, 13 Sep 2010 02:43:03 +1000, Ken McDonell wrote:

 kenj> Some of the suggestions to date include ...

 kenj> + data filtering predicates pushed from a client to pmcd and then on to 
 kenj> a pmda to enable or restrict the types of events or conditions on event 
 kenj> parameters that would be evaluated before asynchronously sending 
 kenj> matching events to the client

How would that work if multiple clients request mutually exclusive

 kenj> + additional per-client state data being held in pmcd to allow rate 
 kenj> aggregation (and similar temporal averaging) to be done at pmcd, rather 
 kenj> than the client [note I have a long-standing objection to this approach 
 kenj> based on the original design criteria that pmcd needs to be mean and 
 kenj> lean to reduce impact, and data reduction and analysis should be pushed 
 kenj> out to the clients where the computation can be done without impacting 
 kenj> the system being monitored ... but maybe it is time to revist this, as 
 kenj> the current environments where PCP is being used may differ from those 
 kenj> we were concerned with in 1994]

Recent (2010) experience on 3rd rate platform suggests that this is
still an issue - doing too much calculation in pmda is adding to the
time it takes to fetch the data, unless pmcd can magically hide delays
induced by calculations it has to make or calculations made by pmda
ALL clients suffer.

 kenj> Depending on the set of goals we agree on, there may even be a place to 
 kenj> consider maintaining the poll-based mechanism, but the export data is a 
 kenj> variable length buffer of all event records (each aggregated and 
 kenj> self-identifying as below) seen since the last poll-based sample.

How will this work with multiple clients? Will the clients get a "snap
time" to indicate when pmda updated its buffer or will pmda need to
remember the state of each client (which would mean dragging client
information into pmda, maintaining that information and somehow
retiring per-client state without affecting the clients).


<Prev in Thread] Current Thread [Next in Thread>