JRuby max active instances

The jruby_max_active_instances setting can be set in multiple places. It controls the maximum number of JRuby instances to allow on the Puppet Server and how many plans can run concurrently in the orchestrator.

Puppet Server jruby_max_active_instances

Console node group

If Puppet Server runs on the primary server: PE Master

If the PuppetDB service runs on compilers: PE Compiler

Parameter

puppet_enterprise::master::puppetserver::jruby_max_active_instances

This parameter is the same as the max_active_instances parameter in the pe-puppet-server.conf settings and in open source Puppet.

Default value

If Puppet Server runs on the primary server, the default value is the number of CPUs minus 1. The minimum is 1, and the maximum is 4.

If the PuppetDB service runs on compilers, the default value is the number of CPUs multiplied by 0.75. The minimum is 1, and the maximum is 24.

Accepted values

An integer representing a number of JRuby instances

How to calculate

As a conservative estimate, one JRuby process uses approximately 512 MB of RAM. For most installations, four JRuby instances are adequate.

Because increasing the maximum number of JRuby instances also increases the amount of RAM used by Puppet Server, make sure to proportionally scale the Puppet ServerJava heap size (java_args). For example, if you set jruby_max_active_instances to 4, set Puppet Server's java_args to at least 2 GB.

Orchestrator jruby_max_active_instances

Running a plan consumes one JRuby instance. If a plan calls other plans, the nested plans use the parent plan's JRuby instance. JRuby instances are deallocated once a plan finishes running, and tasks are not affected by JRuby availability.

Console node group

PE Orchestrator

Parameter

puppet_enterprise::profile::orchestrator::jruby_max_active_instances

Default value

The default value is the orchestrator heap size (java_args) divided by 1024. The minimum is 1.

  • The default value for the orchestrator.jruby.max-requests-per-instance setting in pe-orchestration-services (which is configurable via the puppet_enterprise::profile::orchestrator::max_requests_per_instance parameter in Hiera) has changed from 100000 to 0. This disables JRuby instance flushing.

  • Changing the orchestrator.jruby.max-requests-per-instance setting results in a full restart of the pe-orchestration-services, which is required to clear any leaked memory, rather than a service reload which was previously required.

Accepted values

An integer representing a number of JRuby instances

How to calculate

Because the jruby_max_active_instances default value is derived from the orchestrator heap size (java_args), changing the orchestrator heap size automatically changes the number of JRuby instances available to the orchestrator. For example, setting the orchestrator heap size to 5120 MB allows up to five JRuby instances (or plans) to run concurrently.

If you notice poor performance while running plans, increase the orchestrator Java heap size instead of jruby_max_active_instances. However, keep in mind that allowing too many JRuby instances can reduce system performance, especially if your plans use a lot of memory.