1.117.2 - "scale puma worker count to processor count" causes OOM on multi-core servers with limited RAM

[simon]

Hi,

the 1.117.2 update introduced scaling Puma workers to the processor count. On my server with 12 cores this changed the worker count from the previous default of 3 to 12 — a 4x increase in RAM consumption, causing repeated OOM kills.

Setup:

• Cloudron 9.2.0
• GitLab 1.117.2
• 12 CPU cores, 24GB RAM total
• Small team, ~5 active users

What happened:
Before 1.117.2, GitLab ran stably for years with 7GB RAM limit (3 Puma workers by default via puma.rb). After the update, GitLab immediately started hitting OOM repeatedly — even after raising the memory limit to 14GB, it still consumed 13.99GB and got killed.

The root cause is in start.sh:

cpus=$(nproc 2>/dev/null || echo 2)
export PUMA_WORKERS=$(( cpus < 2 ? 2 : cpus ))

On a 12-core server this sets 12 Puma workers. Each worker consumes ~800MB–1GB RAM, so Puma alone needs ~12GB — before Gitaly, Sidekiq and Redis are counted.

Suggestion:
Either cap PUMA_WORKERS at a reasonable maximum (e.g. 4–6), or provide a way to override it via /app/data/ so admins can tune it for their setup.

Is there a recommended workaround in the meantime?

Thanks

[james]

Hello @simon
Thanks for reporting.
It should be possible to limit the ram usage of the puma workers according to https://docs.gitlab.com/administration/operations/puma/

[simon]

Thanks for the hint
The GitLab docs describe configuring Puma via /etc/gitlab/gitlab.rb, but the Cloudron package doesn't use Omnibus — it has its own Docker-based setup with gitlab.yml and a start.sh script.

In start.sh, the worker count is set like this:

cpus=$(nproc 2>/dev/null || echo 2)
export PUMA_WORKERS=$(( cpus < 2 ? 2 : cpus ))

Since start.sh is read-only inside the container, I can't override PUMA_WORKERS directly. Is there a supported way in the Cloudron GitLab package to override this — for example via a file in /app/data/ or a similar mechanism?

[simon]

I also checked start.sh for any hook mechanism (sourcing a custom file from /app/data/ etc.), there is none. So there is currently no supported way for end users to override PUMA_WORKERS without modifying read-only container files.

A fix would need to come from the package itself, for example by capping the worker count or by reading an override from /app/data/ like:

PUMA_WORKERS=$(( cpus < 2 ? 2 : cpus ))
[[ -f /app/data/puma_workers ]] && PUMA_WORKERS=$(cat /app/data/puma_workers)
export PUMA_WORKERS

Until then, the only workaround is raising the memory limit in Cloudron significantly. On a 12-core server this means ~14-18GB just for GitLab!

[girish]

Yeah, we had this our gitlab instance too. I am fixing this now @simon

[simon]

Even with 18 GiB of RAM allocated to GitLab, I’m constantly seeing OOM messages. So a quick fix would be great.

[james]

Hello @simon
We just published an update for the @gitlab app that reduces the puma work count.

[simon]

Thank you. This solved it.