Hi Frank,
I agree with all the other good points you make about pmcd/pmda
not-ready interaction here, but it looks like we need to revisit
this DSO PMDA topic once more ...?
----- Original Message -----
> [...]
> Over time, we should move away from DSO's anyway,
The components that are DSO's today have been carefully selected as
such, and those decisions are sound. I agree people should have the
choice to change from DSO to daemon if they wish (and they do). The
defaults are working well though and there isn't a compelling reason
to change 'em - e.g. ...
>
> We've seen pmda bugs crash & bring down pmcd.
> I think we've seen memory leaks.
>
In the case of the kernel PMDA in particular, these are not arguments
for using a daemon. The level of importance of the kernel metrics is
so great that a crash in pmdalinux (whether daemon or DSO) may as well
take out pmcd, cos not much useful work is going to happen beyond that
point either way. Given that fact, we should use the more efficient
transfer mechanism there.
Yes, we certainly have fixed some memory leaks in the past. But any
PMDA that leaks as a DSO, still leaks as a daemon. So that's not a
reason to switch either.
If these issues are concerning you, I propose we increase the level
of testing done on the kernel PMDA (we have no pmdalinux tests using
valgrind, IIRC, which needs to change). DSO mode makes this form of
memory-check testing much easier too, ironically (valgrind->pminfo).
I'd also like to see an increase in the kernel PMDA testing done via
the non-/proc-prefix approach to exercise the many little parsers it
has with canned, targeted data access (currently all pmdalinux tests
use the running kernel as the data source, but it doesn't have to be
that way).
Also, bear in mind we have many hosts running pmcd with the current
DSO PMDA set in 24x7 production operation, and have for many years.
We should (and do) have high levels of confidence in this code. It
can be made better still and we must strive to do so, but switching
the kernel PMDA in particular into a daemon does not help us toward
that goal IMO.
cheers.
--
Nathan
|