Skip to content

fix(runtime): use automaxprocs for cgroup-aware GOMAXPROCS#162

Merged
fank merged 3 commits intomainfrom
fix/cgroup-aware-gomaxprocs
Apr 11, 2026
Merged

fix(runtime): use automaxprocs for cgroup-aware GOMAXPROCS#162
fank merged 3 commits intomainfrom
fix/cgroup-aware-gomaxprocs

Conversation

@fank
Copy link
Copy Markdown
Member

@fank fank commented Apr 11, 2026

Summary

  • Add go.uber.org/automaxprocs and call maxprocs.Set in init() instead of the old GOMAXPROCS(numCPUs - 2) math.
  • runtime.NumCPU() returns the host count, not the cgroup quota — on a 24-core host with a 200% Docker CPU limit the old code had Go scheduling 22 OS threads against a 2-core budget, producing exactly the "0 fps for 5-10s" stalls that motivate this PR.

Why

A user running Pelican (Docker) reported their ArmA server hanging during :MISSION:SAVE:. Raising the container CPU limit from 200% to 400% made a 30-minute test pass where 200% had reliably stalled — a textbook CFS-quota oversubscription symptom. The extension's log showed numCPUs=24 even inside the container, confirming that runtime.NumCPU() was returning the host count and that GOMAXPROCS was set to 22. automaxprocs reads /sys/fs/cgroup/cpu.max (cgroup v2) or the v1 equivalents and sets GOMAXPROCS to the actual CPU allowance.

On bare metal / macOS / Windows where there's no cgroup quota, maxprocs.Set falls through to runtime.NumCPU(), so nothing changes.

Test plan

  • go build ./cmd/ocap_recorder
  • go test ./...
  • Manual (optional): run the binary inside a container with `--cpus=2` and confirm the startup log shows `GOMAXPROCS=2`

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request replaces the manual GOMAXPROCS configuration with the go.uber.org/automaxprocs library to automatically adjust CPU quotas in containerized environments. While this improves container compatibility, the reviewer noted that the previous implementation specifically reserved two CPU cores to prevent contention with the host process (ArmA 3). Since automaxprocs defaults to the full core count on bare metal, this change may lead to performance issues if the original 2-core buffer was intentional for stability.

Comment thread cmd/ocap_recorder/main.go
@github-actions
Copy link
Copy Markdown

Merging this branch will not change overall coverage

Impacted Packages Coverage Δ 🤖
github.com/OCAP2/extension/v5/cmd/ocap_recorder 0.00% (ø)

Coverage by file

Changed files (no unit tests)

Changed File Coverage Δ Total Covered Missed 🤖
github.com/OCAP2/extension/v5/cmd/ocap_recorder/main.go 0.00% (ø) 0 0 0

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.

@fank fank merged commit 7ea4314 into main Apr 11, 2026
3 checks passed
@fank fank deleted the fix/cgroup-aware-gomaxprocs branch April 11, 2026 22:02
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