Apparently the size of a response is limited and it cut off the rest of my message.
Here are some others: < 2017-06-30 07:32:05.255 EDT >LOG: duration: 1220.789 ms execute S_6773/C_6774: SELECT fs.certname AS certname, env.name AS environment, fp.name AS name, fv.value AS value FROM factsets fs INNER JOIN facts f ON fs.id = f.factset_id INNER JOIN fact_values fv ON f.fact_value_id = fv.id INNER JOIN fact_paths fp ON f.fact_path_id = fp. id INNER JOIN value_types vt ON vt.id = fv.value_type_id LEFT JOIN environments env ON fs.environment_id = env.id WHERE (fp.depth = 0 AND ((fs.certname = $1) AND ((fs.c ertname) in ( (SELECT certnames.certname AS certname FROM certnames LEFT JOIN catalogs ON certnames.certname = catalogs.certname LEFT JOIN factsets fs ON certnames.cer tname = fs.certname LEFT JOIN reports ON (certnames.certname = reports.certname AND (reports.id in (SELECT latest_report_id FROM certnames))) LEFT JOIN environments cat alog_environment ON catalog_environment.id = catalogs.environment_id LEFT JOIN environments facts_environment ON facts_environment.id = fs.environment_id LEFT JOIN envi ronments reports_environment ON reports_environment.id = reports.environment_id WHERE (certnames.deactivated IS NULL AND certnames.expired IS NULL)) ) ))) < 2017-06-30 07:32:05.255 EDT >DETAIL: parameters: $1 = 'xbpmrxm2s.aetna.com' < 2017-06-30 07:32:05.374 EDT >LOG: duration: 1131.477 ms execute S_6907/C_6908: SELECT fs.certname AS certname, env.name AS environment, fp.name AS name, fv.value AS value FROM factsets fs INNER JOIN facts f ON fs.id = f.factset_id INNER JOIN fact_values fv ON f.fact_value_id = fv.id INNER JOIN fact_paths fp ON f.fact_path_id = fp. id INNER JOIN value_types vt ON vt.id = fv.value_type_id LEFT JOIN environments env ON fs.environment_id = env.id WHERE (fp.depth = 0 AND ((fs.certname = $1) AND ((fs.c ertname) in ( (SELECT certnames.certname AS certname FROM certnames LEFT JOIN catalogs ON certnames.certname = catalogs.certname LEFT JOIN factsets fs ON certnames.cer tname = fs.certname LEFT JOIN reports ON (certnames.certname = reports.certname AND (reports.id in (SELECT latest_report_id FROM certnames))) LEFT JOIN environments cat alog_environment ON catalog_environment.id = catalogs.environment_id LEFT JOIN environments facts_environment ON facts_environment.id = fs.environment_id LEFT JOIN envi ronments reports_environment ON reports_environment.id = reports.environment_id WHERE (certnames.deactivated IS NULL AND certnames.expired IS NULL)) ) ))) < 2017-06-30 07:32:05.374 EDT >DETAIL: parameters: $1 = 'xiibw2d.aetna.com' < 2017-06-30 07:32:05.391 EDT >LOG: duration: 1063.130 ms execute S_7083/C_7084: SELECT fs.certname AS certname, env.name AS environment, fp.name AS name, fv.value AS value FROM factsets fs INNER JOIN facts f ON fs.id = f.factset_id INNER JOIN fact_values fv ON f.fact_value_id = fv.id INNER JOIN fact_paths fp ON f.fact_path_id = fp. id INNER JOIN value_types vt ON vt.id = fv.value_type_id LEFT JOIN environments env ON fs.environment_id = env.id WHERE (fp.depth = 0 AND ((fs.certname = $1) AND ((fs.c ertname) in ( (SELECT certnames.certname AS certname FROM certnames LEFT JOIN catalogs ON certnames.certname = catalogs.certname LEFT JOIN factsets fs ON certnames.cer tname = fs.certname LEFT JOIN reports ON (certnames.certname = reports.certname AND (reports.id in (SELECT latest_report_id FROM certnames))) LEFT JOIN environments cat alog_environment ON catalog_environment.id = catalogs.environment_id LEFT JOIN environments facts_environment ON facts_environment.id = fs.environment_id LEFT JOIN envi ronments reports_environment ON reports_environment.id = reports.environment_id WHERE (certnames.deactivated IS NULL AND certnames.expired IS NULL)) ) ))) < 2017-06-30 07:32:05.391 EDT >DETAIL: parameters: $1 = 'xbpmsbw1q.aetna.com' Also seeing: < 2017-06-30 07:47:49.604 EDT >LOG: checkpoints are occurring too frequently (19 seconds apart) < 2017-06-30 07:47:49.604 EDT >HINT: Consider increasing the configuration parameter "checkpoint_segments". I've already increased that to 32. On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > Last Sunday we hit a wall on our 3.0.2 puppetdb server. The cpu spiked > and the KahaDB logs started to grow eventually almost filling a > filesystem. I stopped the service, removed the mq directory per a > troubleshooting guide, and restarted. After several minutes the same > symptoms began again and I have not been able to come up with a puppetdb or > postgresql config to fix this. > > We tried turning off storeconfig in the puppet.conf file on our puppet > master servers but that doesn't appear to have resolved the problem. I > also can't find a good explanation as to what this parameter really does or > does not do even in the puppet server documentation. Anyone have a better > insight into this? > > Also is there a way to just turn off puppetdb? > > I've attached a file that is a snapshot of the puppetdb dashboard. > > Anyone experience anything like this? > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/41fb8e3f-2eff-49d8-ac16-b704dbdd89c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
