The Puppetserver generates catalogs for each of our agents, using the code placed in our environments and served via JRubies. We'll be configuring the JVM and implementing our changes in Puppet in both an Enterprise and open source installation.

Puppetserver's primary job in our infrastructure is handling agent requests and returning a catalog. In older versions of Puppet, the RubyGem Passenger was commonly used to concurrently serve requests to multiple agents. Today Puppet runs multiple JRuby instances on the Puppetserver to handle concurrent requests. While Ruby itself runs with the operating system's native compiler, JRuby runs Ruby in an isolated JVM instance. These JRubies allow for better scaling with Puppet, providing multiple concurrent and thread-safe runs of Puppet. Each JRuby can serve one agent at a time, and Puppet will queue agents until a JRuby is available.

Every JVM (containing JRuby instances) has a minimum and maximum heap size. The maximum heap size determines how much memory a JVM can consume before garbage collection begins. Garbage collection is simply the process of clearing data from memory, starting from the oldest data to the newest. The minimum heap size ensures that new JVMs are started with enough memory allocated to run the application. If the JRuby can not allocate enough memory to the Puppet instance, it will trigger an OutOfMemory error and shut down the Puppetserver. We generally set our Java maximum heap size (sometimes referred to as -Xmx) and our minimum heap size (-Xms) to the same value, so that new JRubies start with the memory they need. We can also set the maximum number of JRuby instances using the max-active-instances. Puppet generally recommends this number be close to the number of CPUs available to the Puppetserver.