So I went to run the curl command listed below and it came back with nothing. So I used pgadmin to look at the catalogs table and it's completely empty. The system has been running for almost 24 hours after dropping/creating the postgresql database. Any idea why the catalog table would be empty?
On Wednesday, June 28, 2017 at 2:11:17 PM UTC-4, Mike Sharpton wrote: > > Hey all, > > I am hoping there is someone else in the same boat as I am. We are > running Puppet 4.2.2, along with PuppetDB 4.3.0. I am seeing low > duplication rate which I think is contributing to our queuing problems in > PuppetDB. The queue will fluctuate from 0-100 queued, to up to 2000. We > have around 4500 nodes, and we are using 8 threads on our PuppetDB server. > I am seeing that the low duplication rate is caused by hashes not matching > and a full insert running which is expensive on the DB instead of just > updating the time stamp. I don't know why these would not be matching, and > may need help as far as how to find something like this. I see items in > PuppetDB3 for this, but not 4. I see that using timestamp and other items > which change each time will cause the catalog to never be the same, but I > would think we would have 0% duplication if this was the case. I am also > seeing that things are improved in 4.4.0 as far as performance and a > missing index is corrected that may speed things. I am wondering what > others have done/seen with this and whether upgrading to 4.4.0 would do me > good. I am thinking it would as many things appear to fixed around the > issues I am seeing. Thanks in advance, > > Mike > -- 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/d2aad3a9-40d2-4d79-bb46-32e2ffe357e5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
