Chris, Thanks for the detailed response. BTW did you deploy HA, load balancing, etc on the Postgres side?
Cheers On Thu, Jun 25, 2015 at 11:11 PM, Christopher Wood < [email protected]> wrote: > Somewhere past 700 nodes (still puppetizing) our 1-core, 2GB-RAM > puppetmasters and 2-core, 2GB-RAM puppetdb host started showing signs of > overload (ssl/connect errors in agent logs, catalog/report mismatches in > puppetdb). I augmented the VMs with "hardware" to stop the complaints and > later on went off tuning. I moved the puppetmasters up to 4-core 8GB-RAM > and the puppetdb host is now 4-core 16GB-RAM. Definitely rattling around in > them now but there's lots of room for growth. > > For scaling/tuning, among others: > > > https://ask.puppetlabs.com/question/13433/how-should-i-tune-passenger-to-run-puppet/ > > https://docs.puppetlabs.com/puppetdb/latest/scaling_recommendations.html > > https://docs.puppetlabs.com/guides/scaling.html > > http://activemq.apache.org/scaling-queues.html > > http://activemq.apache.org/javalangoutofmemory.html > > After all that I analyzed catalogs across the deployment and found that > the datacat usage in the mcollective module (now > https://github.com/puppet-community/puppet-mcollective) was an abominable > percentage of the total number of resources. The firewall type ( > https://github.com/puppetlabs/puppetlabs-firewall) was 3% of the total > resources. Since it takes less horsepower to puppet up fewer things I > figure there will be a benefit in some judicious refactoring here and > there. (Templates instead of file_line, iptables config instead of firewall > resources, et cetera.) > > However, I figure there's a benefit in a conversion effort to cram things > into puppet first and sort them out later. I had a good time just throwing > hardware at the problem to start and then tuning after the bulk of hosts > were converted to puppet management. People at companies where incremental > hardware use is expensive may want to tune early and shrink manifests more > aggressively. > > On Thu, Jun 25, 2015 at 08:16:31PM -0400, Tom Tucker wrote: > > Assuming 2,500 Linux clients running Puppet community edition 3.8. > Any > > sizing recommendation for a PuppetDB system in regards to disk size > for > > the DB, CPU, Memory, etc. > > Thank you for your time and feedback. > > > > -- > > 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 [1][email protected]. > > To view this discussion on the web visit > > [2] > https://groups.google.com/d/msgid/puppet-users/CAGymF1CQpBBFRZ2VO5x_e5XEt2sxF6Zpe_cT%2BZUaT5NbO%2BcEYA%40mail.gmail.com > . > > For more options, visit [3]https://groups.google.com/d/optout. > > > > References > > > > Visible links > > 1. mailto:[email protected] > > 2. > https://groups.google.com/d/msgid/puppet-users/CAGymF1CQpBBFRZ2VO5x_e5XEt2sxF6Zpe_cT%2BZUaT5NbO%2BcEYA%40mail.gmail.com?utm_medium=email&utm_source=footer > > 3. https://groups.google.com/d/optout > > -- > 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/20150626031113.GA832%40iniquitous.heresiarch.ca > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAGymF1CXG4cfFfFDEv4vRkko558un3Duo89LpqTTaHd1VmkQRQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
