On 07/07/15 17:50, Pieter Baele wrote:
...
Indeed.
But a service pcp restart brought some data, until a pminfo -f is used,
ok 1025 44321 ipv6 INADDR_ANY
[Tue Jul 7 09:26:13] pmcd(16292) Info: CleanupAgent ...
Cleanup "postgresql" agent (dom 110): protocol failure for fd=26, signal(11)
Ouch. signal 11 is SIGSEGV which is not supposed to happen for a PMDA!
2. next inspect /var/log/pcp/pmcd/postgresql.log (and possibly
.../postgresql.log.prev if pmcd has tried to restart the PMDA).
If the answer is not obvious (I'd expect a DBI connect issue or more
likely a permissions problem that prevents the user the PMDA is
using from selecting from the stats tables), post the postgresql.log
and pmcd.log files.
Correct. I've the feeling it's a weak point, as I had the same problem
on the community version (no postgresql PMDA data once I used a pminfo -f)
ex. postgresql.stat.all_tables.last_analyze: pmLookupName: No PMCD agent
for domain of request
But also
[Tue Jul 7 09:48:03] pmdapostgresql(8911) Info: Skipping table
pg_stat_database_conflicts, not supported on EnterpriseDB 9.4.1.4 on
x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat
4.4.7-11), 64-bit
As our DB's are maintained by a separate DBA team, I'll ask them what I
need to query pg_stat*
Addressing that may, or may not, fix the problem you're having.
I'd like to concentrate on the SIGSEGV ... but I'll move that discussion
off the list as it is unlikely to be informative to the broader audience.
|