Question
Resource Class Allocation and Parallelism Concurrency Limits
Rin Finch
0 reputation · 13 Jan 2020, 07:29 UTC
134.7K views1
Loading…
0 reputation · 13 Jan 2020, 07:29 UTC
CircleCI allows the definition of resource_class to manage CPU and RAM allocations, while the parallelism parameter splits jobs across multiple concurrent containers to reduce execution time.
When scaling a pipeline, there is a need to balance high parallelism with organization-level concurrency limits to ensure that resource-intensive jobs do not saturate available runner capacity or exhaust credits prematurely.
It is unclear how the orchestrator prioritizes resource allocation when multiple pipelines with high parallelism settings compete for the same limited concurrency slots.
33775 reputation · 13 Jan 2020, 18:57 UTC
CircleCI’s organization‑wide concurrency limit is a cap on the number of concurrent containers that can be running at any moment. Each container is one unit of the limit, regardless of the resource_class it requests. Therefore:
circleciparallelism: 4 will occupy four slots of the limit.resource_class: xlarge job still consumes one concurrency slot, but it gets more CPU and RAM inside that slot.CircleCI will:
resource_class that is not available on any idle runner, it will also be queued until a suitable runner appears.parallelism values across jobs.resource_class only to match the workload’s CPU/RAM needs; it won’t affect concurrency slots.To give a more precise recommendation, could you let us know if you are using any custom resource classes or the machine executor? This influences how runners are matched to jobs.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 13 Jan 2020, 18:53 UTC
Parallelism and resource_class interact on cost as well as slots. Each parallel container counts as one concurrency unit, but credits are consumed per container-minute at the rate defined for that resource class. A high-parallelism job on a larger class therefore burns credits faster in wall-clock time than the same parallelism on a smaller class, even though slot usage is identical.
This is separate from the cloud concurrency cap: self-hosted runners are bounded by the runner agent and host capacity you provision, not by the plan concurrency limit. There is no built-in per-pipeline priority scheduler; contention is typically managed by capping parallelism or staggering workflows.
Verification in the usage export and plan pages is recommended, as exact rates and class names vary by plan and executor.