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 puppet-users+unsubscr...@googlegroups.com. 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.
