Thanks JM. Your config files look good and the existence of all of those tables in your puppetdb database certainly makes it look as though puppetdb is communicating with postgres properly. Since increasing the heap size seems to have gotten you past the issues for now, my next guess is that it is some combination of catalog size and number of concurrent agent requests, and perhaps number of cores on your machine. We would love to investigate further, so if you are willing to share a postgres dump with us that would be fantastic!
I'll e-mail you off-list to follow up on that. I'd also be interested in seeing the output of 'cat /proc/cpuinfo'. Thanks! Chris On Wednesday, August 8, 2012 1:08:09 AM UTC-7, A_SAAS wrote: > > Hi, > > The configuration files are attached. > > Here is the postgres login: > [root@puppetmaster]:/data/local/postgresql/dumps # psql -h localhost > puppetdb puppetdb > psql (8.4.12) > SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) > Type "help" for help. > > puppetdb=> \l > List of databases > Name | Owner | Encoding | Collation | Ctype | Access privileges > > -----------+----------+-----------+-----------+-------+----------------------- > postgres | postgres | SQL_ASCII | C | C | > puppetdb | puppetdb | SQL_ASCII | C | C | > template0 | postgres | SQL_ASCII | C | C | =c/postgres > : > postgres=CTc/postgres > template1 | postgres | SQL_ASCII | C | C | =c/postgres > : > postgres=CTc/postgres > (4 rows) > puppetdb=> \d > List of relations > Schema | Name | Type | Owner > --------+-------------------------+-------+---------- > public | catalog_resources | table | puppetdb > public | catalogs | table | puppetdb > public | certname_catalogs | table | puppetdb > public | certname_facts | table | puppetdb > public | certname_facts_metadata | table | puppetdb > public | certnames | table | puppetdb > public | classes | table | puppetdb > public | edges | table | puppetdb > public | resource_params | table | puppetdb > public | schema_migrations | table | puppetdb > public | tags | table | puppetdb > > > And by the way I changed the JVM max heap at 256M and since then no issue. > Regarding the postgres dump file, I'll be willing to give it to you so > contact me in private to get the URL or let me know where I can put it as > long as nobody could access it publicly. > > > Regards, > JM > > > > > On Tue, Aug 7, 2012 at 6:59 PM, Chris Price <ch...@puppetlabs.com<javascript:> > > wrote: > >> JM, >> >> Hmm... so, those versions of Java seem fine--those are probably the ones >> we've done the most testing with. >> >> So, the error message that you sent indicates that the JVM is running out >> of RAM. This could possibly indicate that you are still using the embedded >> database instead of postgres--the embedded database uses a lot of RAM. Can >> we see what your database.ini file looks like? In fact, perhaps we can >> take a look at all of the files in your /etc/puppetdb/conf.d directory? >> >> You could also connect directly to your postgres database using psql or >> pgadmin, and check to see if the puppetdb tables exist and contain data. >> >> The only other possibility that I can think of would be if one or more of >> your nodes has an extremely large catalog, and that the puppetdb JVM >> instance doesn't have enough memory to process the catalog. If that's the >> case, we can try increasing your JVM max heap space in >> /etc/default/puppetdb... but we would be really interested in collecting >> some data from you about what that catalog looks like (for our own testing >> and debugging purposes) if it turns out that that is the culprit. >> >> Thanks! >> Chris >> >> On Wednesday, August 8, 2012 1:08:09 AM UTC-7, A_SAAS wrote: > > Hi, > > The configuration files are attached. > > Here is the postgres login: > [root@puppetmaster]:/data/local/postgresql/dumps # psql -h localhost > puppetdb puppetdb > psql (8.4.12) > SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) > Type "help" for help. > > puppetdb=> \l > List of databases > Name | Owner | Encoding | Collation | Ctype | Access privileges > > -----------+----------+-----------+-----------+-------+----------------------- > postgres | postgres | SQL_ASCII | C | C | > puppetdb | puppetdb | SQL_ASCII | C | C | > template0 | postgres | SQL_ASCII | C | C | =c/postgres > : > postgres=CTc/postgres > template1 | postgres | SQL_ASCII | C | C | =c/postgres > : > postgres=CTc/postgres > (4 rows) > puppetdb=> \d > List of relations > Schema | Name | Type | Owner > --------+-------------------------+-------+---------- > public | catalog_resources | table | puppetdb > public | catalogs | table | puppetdb > public | certname_catalogs | table | puppetdb > public | certname_facts | table | puppetdb > public | certname_facts_metadata | table | puppetdb > public | certnames | table | puppetdb > public | classes | table | puppetdb > public | edges | table | puppetdb > public | resource_params | table | puppetdb > public | schema_migrations | table | puppetdb > public | tags | table | puppetdb > > > And by the way I changed the JVM max heap at 256M and since then no issue. > Regarding the postgres dump file, I'll be willing to give it to you so > contact me in private to get the URL or let me know where I can put it as > long as nobody could access it publicly. > > > Regards, > JM > > > > > On Tue, Aug 7, 2012 at 6:59 PM, Chris Price <ch...@puppetlabs.com<javascript:> > > wrote: > >> JM, >> >> Hmm... so, those versions of Java seem fine--those are probably the ones >> we've done the most testing with. >> >> So, the error message that you sent indicates that the JVM is running out >> of RAM. This could possibly indicate that you are still using the embedded >> database instead of postgres--the embedded database uses a lot of RAM. Can >> we see what your database.ini file looks like? In fact, perhaps we can >> take a look at all of the files in your /etc/puppetdb/conf.d directory? >> >> You could also connect directly to your postgres database using psql or >> pgadmin, and check to see if the puppetdb tables exist and contain data. >> >> The only other possibility that I can think of would be if one or more of >> your nodes has an extremely large catalog, and that the puppetdb JVM >> instance doesn't have enough memory to process the catalog. If that's the >> case, we can try increasing your JVM max heap space in >> /etc/default/puppetdb... but we would be really interested in collecting >> some data from you about what that catalog looks like (for our own testing >> and debugging purposes) if it turns out that that is the culprit. >> >> Thanks! >> Chris >> >> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/zwXstXYZfFgJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
