Hi, Ken -
> > (Sure, generally speaking; but for lesser intensity, it could be fine.
> > Must measure.)
>
> Indeed it depends on the data rate ... I think of systemtap (and kernel
> instrumentation in general) to be at the heavy lifting end of the spectrum
> in terms of data rates and size, and expect that event trace data might be
> even more so. [...]
That sounds right, though systemtap is often used to compress &
analyze the data from a system in situ (where it's most efficient),
before reporting it to userspace. Similarly for tracing - stap
scripts don't normally bother report each microscopic event, but
larger richer derived events/values. While one can program a
particular stap script otherwise, the data rates may not be that high.
Must measure.
> > > The mmv model has worked well in the past. [...]
> >
> > It would be nice if we used it ourselves (outside QA toys), so we could
> > experience its robustness & utility right in the code we ship.
>
> As Nathan has said ... "The MMV code in PCP has been around for quite some
> time, and I know of a number of production environments using it 24x7 on
> hundreds of machines, for many years - its not fragile at all. "
No one's disputing that, especially considering the extent to which
those production environments were assisted by PCP developers, who
were well aware how the code worked and didn't need to stray from the
super stable parts.
> Because of the way the mmv pmda is written, it is likely that the
> most common use case will be for instrumentation of applications
> that do not already have a performance data export channel (IPC, log
> file, status file, callback routine, system call) and are looking
> for an easy to implement and low overhead option. So by definition,
> most of the uses will be outside the PCP project's code base.
That doesn't quite follow. Some places within pcp where we do have
log files, ipc, status file etc. kinds of mechanisms just to share
some data, could use MMV instead. Those log files could be exported
to special clients, as could stats/reports about internal operations
of nontrivial servers. It could be an upgrade from one-off shmem
protocols crafted for pmcd.{pmie,pmlogger,...}.
> [...]
> Sceptical eyes are always welcome ... I'd be happy to take these issues on
> board to inform a plan to improve the mmv pmda. Since these are your
> observations, could you open a bz issue so we can track 'em?
Sure thing.
> The DSO pmda issue is however not really an mmv problem, it is a general
> caveat on any PMDA that is added as a DSO, namely pmcd is exposed to coding
> errors in the PMDA.
Indeed so. (Only not just coding errors in the sense of outright
bugs, but sensitivity to malevolent environments.) Note even the
unprivileged process PMDAs may run as user 'pcp', which is not
entirely unprivileged. setuid-pcp processes can muck with directories
like /var/lib/pcp/tmp, /var/lib/pcp/config, /etc/pcp/pmie,
/etc/pcp/pmlogger... so there are some slightly attractive targets
there too.
- FChE
|