pmlogconf simply takes too long. The task of probing for some dozens of metrics should not take *minutes*, but because of the shell-script/awk/pmprobe based implementation, and because of derived-metrics amplifying traffic further, it easily does, esp. with busy networks & remote hosts. For more analysis, see http://www.pcp.io/pipermail/pcp/2016-May/010540.html Partial improvement patch: https://sourceware.org/git/gitweb.cgi?p=pcpfans.git;a=commitdiff;h=8a158581ddc58d7f50f53f4688631f8f82a29b1a But really it should be rewritten in python or something.
That patch looks good to me and is basically the agreed solution as discussed http://www.pcp.io/pipermail/pcp/2016-May/010545.html i.e. turn off derived metrics in pmlogconf by setting PCP_DERIVED_CONFIG to an empty string, along with suitable man page updates. Not sure if we'd still want to honor PCP_DERIVED_CONFIG if it is already set to something (as opposed to not being set) ?? > > But really it should be rewritten in python or something. I don't see how reimplementing pmlogconf in another language will reduce the probe overheads - we'd still have the same number of probes being called, which is surely where most of the time is being spent. But the above patch should help.
> > But really it should be rewritten in python or something. > > I don't see how reimplementing pmlogconf in another language will reduce the > probe overheads - we'd still have the same number of probes being called I was imagining a self-contained program that implements all of the pmlogconf logic, so without overheads of many pmprobe child processes, retaining a persistent pcp connection to do the individual metric probes, that sort of thing. That should take only a few dozen pcp wire protocol packets total, and a fraction of a second.
Just caching the value of kernel.uname.sysname will probably make a worth while improvement : # grep -r '^probe.*sysname' /var/lib/pcp/config/pmlogconf | wc -l 24 In any case, if we're going to have a rewrite, there are some usability improvements that should be made too (we shouldn't be getting bugs like #1358972). And also need to expunge the obsolete IRIX config entries.
pmlogconf is part of the main pcp package which has no dependency on python, and its highly desirable that it remain that way (some platforms won't necessarily have python installed at all). | I don't see how reimplementing pmlogconf in another language will reduce the probe [...] FWIW, with some refactoring all of the metrics could be fetched in a single pmprobe/pminfo invocation - see pcp-summary for an example - there's alot of scope for improving the existing code.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
pcp-3.12.0-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d29400ff30
pcp-3.12.0-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9103ca28d1
pcp-3.12.0-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d29400ff30
pcp-3.12.0-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9103ca28d1
pcp-3.12.0-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.12.0-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.