GitHub Actions: runnerのリソースについて

buildが同一runner上でCPU/ネットワーク帯域を奪い合っている可能性が高いです

  • GitHub-hosted標準runner(2コア)だと、3並列buildの恩恵がリソース競合で相殺されやすい構造だと思われる

前提：runnerのスペック

GitHub-hosted runners reference の “Standard GitHub-hosted runners for private repositories” の表より、ubuntu-latestは

Processor (CPU)Memory (RAM)Storage (SSD)
28 GB14 GB
  • 8 GB = メモリ（RAM）、14 GB = ディスク容量（SSD）。別物なので混同しない
  • publicリポジトリだと同じubuntu-latestでも 4 CPU / 16 GB / 14 GB と倍のスペックになる

CIのリソースとは？

runnerという1台のVMを、並列buildが分け合っている。競合するのは主に4つ。

  • CPU（論理CPU数） … コンパイル・minifyなど「計算そのもの」
  • メモリ（8 GB） … 並列数だけプロセスが立つので山分けになる。使い切ると OOM（Out Of Memory）でプロセスがカーネルに強制終了される。CIで突然 Exit code 137 で落ちるのがこれ
  • ディスクI/O・容量（14 GB） … I/O は読み書きの速さ。npm installの展開やdocker buildのレイヤー書き込みは大量の小さいファイル書き込みで、CPUではなくディスク待ちになりやすい。容量も14 GBしかなく、3並列分のイメージやキャッシュを置くと No space left on device で落ちる
  • ネットワーク帯域 … docker pullや依存パッケージの取得。VM単位で共有なので、並列にしても総ダウンロード時間は縮まない

CPUについては 2026/07/09 の話がそのまま効く。2 vCPU = 同時に走れるプロセスは2つまでという天井なので、1job内で3並列にしても3本目は並列（parallelism）にならず、タイムスライスで奪い合う並行（concurrency）にしかならない。コンテキストスイッチのコストも乗る。

論理CPU0: │ B1 │ B3 │ B1 │ B3 │ ...
論理CPU1: │ B2 │ B2 │ B2 │ B2 │ ...
           └─ 同時に走れるのは2本まで

対処

  • jobを分ける：job単位で別VMが割り当たるので、3jobに分ければ 2 vCPU × 3台になる
  • larger runnerを使う：1jobのまま並列度を上げたいなら vCPU を増やす（課金増）。Larger runners reference より 2〜96 vCPU から選択可能
  • 並列度をvCPU数に合わせる：CPUバウンド（＝処理時間の大半をCPU計算が占める仕事。対義語は、通信やディスクの「待ち」が大半を占めるI/Oバウンド）なら 並列数 = 論理CPU数 が基本
    • I/Oバウンドな処理は待っている間CPUが空くので、vCPU数より多い並列度でも効果が出る。逆にCPUバウンドで増やしすぎるとコンテキストスイッチ分だけ遅くなる