Is anyone using puppet server 2.0.0 successfully?

73 views
Skip to first unread message

Johnson Earls

unread,
May 4, 2015, 7:25:24 PM5/4/15
to puppet...@googlegroups.com
Hey folks,

I just wanted to find out if anyone has been successful in setting up puppet server 2.0.0 and running it?

I ask because, in my test deployment with the puppet server and one puppet agent, the puppet server crashed after less than 5 hours with an out of memory error.  I've just restarted it about an hour ago, so I'll see if it repeats itself.

I'm running Oracle Linux 6.6 on an Oracle SUN X4-2 server with 256GB RAM - not trying it in VMs yet.  The only things I could think of that are out-of-the-ordinary in my setup are (a) agents are updating every 10 minutes, (b) the agent on the non-server test node does not have a server role configured, so it's just generating a fail() message in the site.pp manifest, and (c) the puppet server is running the openjdk version of java 1.7.

If anyone has any advice about running (or not running) puppet server 2.0.0 in a production deployment, I'd love to hear it.

Thanks in advance,
- Johnson

Johnson Earls

unread,
May 5, 2015, 2:23:52 AM5/5/15
to puppet...@googlegroups.com
Okay, so it turns out that puppet server 2.0.0 has a default setting for the maximum number of ruby threads that is equal to 2 more than the number of CPUs in the system.  SInce I'm running on a system with 48 CPUs [threads], puppetserver was starting 50 ruby threads, and quickly overran the [also default] 2GB heap size.  I have reset the `max-active-instances` parameter to 4, and we'll see how that goes.  I need to figure out how long an average catalog will take to generate and work out how many ruby threads I need to support 250 nodes doing updates every 10 minutes.

- Johnson

Chris Barbour

unread,
May 5, 2015, 11:16:27 AM5/5/15
to puppet...@googlegroups.com
I recall reading that this default has changed in the latest releases of Puppetserver for the reasons you cite. If this host is a dedicated Puppemaster, be aware that the number of threads will dramatically affect the throughput of your master.

Determining catalog compile time is pretty simple; check the last_run_summary.yaml document on one of your larger agents. Take the number for the catalog compile time, multiply it by the number of nodes to see how much processor time you require on your masters. Divide that by your run interval (10m) to determine the number of cores required, and add a bit of a buffer for future growth and load spikes.
Reply all
Reply to author
Forward
0 new messages