Hi, Ken -
kenj wrote:
> [...]
> I agree on the strace for PMDA not pmcd comments.
>
>> ...
>> Come to think of it, there are few PMDAs that have NOT been hit by
>> this issue at some point. I wonder if it's time that a more systemic
>> solution be invented (not just restarting timed-out pmdas).
>
> But I think this assertion is not correct ... there are in fact very
> few PMDAs that have hit this issue, specifically there are 81 PMDAs in
> the current source tree and very few of these have triggered PDU
> timeout issues for pmcd. The most notable and long-standing cases are
> the DBMS PMDAs where SQL queries are used.
Sorry, I was not speaking of the complete census of 81. Of the
handful of ones activated by default, plus a few activated by
curiosity, I've encountered timeouts for most of them: pmdalinux,
pmdaproc, pmdasystemd, pmdapapi, pmdarpm, probably even pmdammv, all
in living memory.
> And the "solution" is a standard one ...
> [...]
And I wonder if libpcp_pmda should automate it so pmdas don't have to
reinvent it.
> [...] This [background-thread] approach reduces the quality of the
> data (in terms of timeliness) and adds overhead (the refreshing
> thread runs even if no client of pmcd is requesting the data).
> [...]
The second part of that need not be true. The PMDA could be
responsive to clients asking for data, and start its poll thread only
during such times and even only at such observed fetching rates.
- FChE
|