How to Right-Size CPU for a CI Build
A bigger runner only helps a CPU-bound build. Right-sizing CPU means matching cores to where the build actually parallelizes, not buying the largest box.
Throwing more CPU at an I/O-bound or single-threaded build wastes money. Right-sizing starts with finding where the build is CPU-bound, then matching core count and tool parallelism to it.
1. Confirm the build is CPU-bound
Check whether CPU is actually the bottleneck before scaling cores. A build pegged at one core will not benefit from more.
- run: |
/usr/bin/time -v npm run build 2>&1 | grep -E 'Percent of CPU|Elapsed'2. Match tool parallelism to cores
A 16-core runner does nothing if the build runs single-threaded. Set the parallelism flag to the core count.
- run: make -j$(nproc) build
- run: npx jest --maxWorkers=$(nproc)3. Avoid paying for idle cores
Cores past the point where the build scales are pure cost. Latchkey lets you pick a right-sized runner so a build that scales to 4 cores is not billed for 16 idle ones.
4. Tie the choice back to cost
A larger runner finishing faster can be cheaper per run, or not, depending on the scaling curve. Model it with the cost calculator at /learn/github-actions-cost-calculator before committing to a size.
Key takeaways
- Confirm the build is CPU-bound before adding cores.
- Match tool parallelism flags to the core count or the cores sit idle.
- Right-size so you do not pay for cores the build never uses.