Hi -
On Thu, Jan 23, 2014 at 01:46:37AM -0500, Nathan Scott wrote:
> [...]
> > % pmval -S '-30 days' -d -h SERVERHOST foo.metric
>
> Assuming there's 30 days worth of data to be found, I think the above
> (thanks to that pesky __pmtimevalSleep in pmval.c) will take ~30 days
> to print its first live sample (default pmval sampling interval being
> 1 second). [...]
That was just an example of how -h and -S can work together, not
saying that this would be horribly sensible sort of output to wait
through.
> That sleep is the central point here & it embodies the core problem,
> as I see it, which is that host context API callers will sleep
> before fetching [...] So, as a user, what I'd expect to see the
> above invocation do is to dump out all that historical data
> immediately, and then begin the sampling of live data (assumes the
> tool sleeps in-between samples, such that each sample is taken at an
> appropriate time).
This behavior would have to be managed by the client, and its most
natural user interface would be
% pmval -S '-30 days' -h SERVERHOST foo.metric
(i.e., no -d). So then, pmval.c would have to detect as it's
exhausted the historical archive and reached current time, which is
something that the pmtime mechanism can tell it. In pmval's main
loop, this part:
/* wait till time for sample */
if (!gui && (pauseFlag || archive == NULL))
__pmtimevalSleep(delta);
could be changed to trigger sleeping if we've caught up, e.g. if the
last result-set's timestamp is within delta of the current time. But
looking closer at it, in the live-archive-server case, we'd behave as
though archive==NULL normally, so the final conditional could be even
simpler.
Nothing clever in libpcp, no inserted sleeps, as nature intended :-)
By the way, wouldn't this issue affect intelligent-libpcp or
live-archive-server approaches equally? Or were you thinking of
PM_CONTEXT_UNIFIED-mode causing sleeps to be inserted within
libpcp/pmFetch?
- FChE
|