Skip to content

Reduce Puma and Pulp worker counts for development tuning - #1

Closed
pablomh wants to merge 1 commit into
developfrom
reduce-dev-tuning-resources
Closed

pablomh wants to merge 1 commit into
developfrom
reduce-dev-tuning-resources

Conversation

@pablomh

@pablomh pablomh commented Oct 8, 2026

Copy link
Copy Markdown
Owner

Why are you introducing these changes?

Puma and Pulp worker/process counts are derived from live hardware facts (processor count, memory) rather than from the selected --tuning profile:

  • foreman::foreman_service_puma_workers defaults to floor(min(100, cores*1.5, mem_gb-1.5))
  • foreman_proxy_content::pulpcore_worker_count defaults to min(8, cores)
  • pulpcore::content_service_worker_count defaults to 2*min(8,cores)+1
  • pulpcore::api_service_worker_count defaults to min(4,cores)+1

This means --tuning development's minimal hardware floor (1 CPU core / 6 GB, see hooks/pre_commit/13-tuning.rb) doesn't actually cap these: any development box above that floor (e.g. a forklift VM with a few cores and more RAM) scales them up the same as default/medium would, and can OOM when Pulp syncs several repositories concurrently.

config/foreman.hiera/tuning/sizes/development.yaml didn't exist before this change, so development silently fell back to tuning/common.yaml with no profile-specific override, unlike medium/large/extra-large/extra-extra-large, which each have one.

Ports theforeman/foremanctl#925 (which fixed the equivalent problem in the container-based installer) to the RPM/Puppet installer.

What are the changes?

  • Add config/foreman.hiera/tuning/sizes/development.yaml, pinning the four worker counts above to 2, the same hiera-override mechanism already used by the other tuning sizes.
  • Add spec/tuning_spec.rb asserting those values, mirroring foremanctl's own tests/unit/tuning_test.py.

Fixes #39882

Test plan

  • CI green
  • rspec spec/tuning_spec.rb passes locally
  • rubocop clean on the new spec

🤖 Generated with Claude Code

Puma and Pulp worker/process counts are derived from live hardware
facts (processor count, memory) rather than from the selected
--tuning profile:

- foreman::foreman_service_puma_workers defaults to
  floor(min(100, cores*1.5, mem_gb-1.5))
- foreman_proxy_content::pulpcore_worker_count defaults to
  min(8, cores)
- pulpcore::content_service_worker_count defaults to
  2*min(8,cores)+1
- pulpcore::api_service_worker_count defaults to min(4,cores)+1

so development's minimal hardware floor (1 CPU core / 6 GB, see
hooks/pre_commit/13-tuning.rb) doesn't actually cap these: any
development box above that floor scales them up the same as
default/medium would, and can OOM when Pulp syncs several
repositories concurrently.

config/foreman.hiera/tuning/sizes/development.yaml didn't exist
before this change, so development silently fell back to
tuning/common.yaml with no profile-specific override, unlike
medium/large/extra-large/extra-extra-large which each have one.

Pin the four worker counts above to 2 for development, the same
hiera-override mechanism already used by the other tuning sizes.

Ports theforeman/foremanctl#925 (which fixed the equivalent problem
in the container-based installer) to the RPM/Puppet installer.

Fixes #39882

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant