GitLab RunnerのVPSには専有vCPUがいくつ必要ですか？

1つのVPSで同時に実行できるCIジョブはいくつですか？

CIジョブ1つには2つの専用vCPUと、それに付随するRAMが必要です。ランナーのconcurrent設定によって、そうしたジョブをいくつVPSで共有するかが決まります。 config.tomlでは、concurrentが登録されたすべてのランナーにわたるジョブ数を制限し、limitが登録された1つのランナーのジョブ数を制限します（デフォルトの0は無制限を意味します）。GitLabの要件ページでは、サイジングの基準となる3つの入力として、ジョブのCPU負荷、メモリ使用量、同時実行数を挙げています。

GitLabのホステッドランナーのサイズはVPSとどう比較できますか？

GitLabのホステッドLinuxランナーはvCPUあたり4 GBのRAMを提供し、CobaltfellのプランはvCPUあたり2 GBを提供します。 vCPU数は1対1で対応するため、この表はすでにGitLab.comで実行しているパイプラインのサイズを選ぶ直接的な方法となります。現在のマシンのメモリの大部分を使用するジョブには、Cobaltfellのプランを1つ上のサイズにするか、同時ジョブ数を減らす必要があります。

Cobaltfellの2026年11月2日の調査によると、2022年以降のプロセッサ上の専用vCPU 1つは、IDチェックなしで暗号資産を受け付けるホストで月額中央値$8.20でした。したがって、2 vCPUの並列CIジョブ1つあたりのコストはその約2倍になります。

この中央値の背後にあるすべてのホストと価格は、2026年11月に専用CPU VPSのコアあたりのコストはいくらかに掲載しています。

CIやコンパイルジョブで専用コアが重要なのはなぜですか？

ビルドはCPUを何分にもわたってフル負荷で占有します。これは共有VPSプランが制限するように作られているまさにそのパターンです。 同じ調査のホスト2社がこれを規約に明記しています。Spartan Hostの規約では、割り当てられたコアの50%を1時間以上超えて使用することを禁止しており、Advin Serversの公正使用ポリシーではCPU使用率を75%に制限しています。

共有vCPUでは、コストはsteal timeとしても現れます。静かな夜には速いパイプラインがピーク時間帯には長引き、コードとは無関係の理由でジョブのタイムアウトが発生します。CPU steal timeとは何か、VPSで確認する方法では、その読み取り方を説明しています。

Cobaltfellの場合：ワークロードが必要とする限り、フル負荷が許可されます。CPUクレジットもバースト時間枠もなく、100%で数分経過してもスロットリングされません。vCPUはホストプロセッサのハードウェアスレッド1つ分です。お客様のvCPUはVPSに1対1で固定され、他のお客様に貸し出されることはなく、物理コアの2つのスレッドは常にペアで割り当てられます。そのため、2 vCPUごとに隣人と共有しない完全なコア1つになります。スレッド上に隣人がいないため、キャッシュが温まったパイプラインは実行ごとにほぼ同じ時間で完了し、遅いジョブはコードを指し示します。vCPUとコアのルールの仕組みは専用vCPUはコアかスレッドかで説明しています。

並列ビルドが同じvCPUを取り合うのを止めるにはどうすればよいですか？

各ジョブにVPSの固定シェアを割り当て、同じ数値をビルドツールに渡します。 ビルドツールはデフォルトで意見が分かれます。GNU makeは-jを指定しない限りレシピを1つずつ実行します。Cargoは論理CPUの数だけジョブを実行します。Ninjaは指定されなくてもCPU数に基づいて並列実行します。Fell 8上でこのようなビルドを4つ実行すると、それぞれが8つのコンパイラを起動します。8スレッドと16 GBのRAMに対して32プロセスです。

Docker executorでは、各ジョブが独自のコンテナで実行され、[runners.docker]がそのコンテナに対してcpusとmemoryの制限を受け取ります。両方を設定し、ジョブ内の並列度を合わせます：

concurrent = 4            # jobs at once, all runners together
check_interval = 3

[[runners]]
  name = "fell-8-docker"
  url = "https://gitlab.com"
  token = "REPLACE_WITH_YOUR_RUNNER_TOKEN"
  executor = "docker"
  limit = 4
  [runners.docker]
    image = "debian:13"
    cpus = "2"             # CPUs for each job container
    memory = "3g"          # leaves room for the system and Docker

variables:
  MAKEFLAGS: "-j2"          # GNU make
  CARGO_BUILD_JOBS: "2"     # cargo (build.jobs)

build:
  script:
    - make
    - cargo build --release
    - ninja -C build -j 2

RustやC++のコンパイルにはVPS上で何が必要ですか？

コンパイルにはスレッドとメモリが歩調を合わせて必要です。並列コンパイラプロセスごと、リンクステップごとに、それぞれが独自のRAMシェアを消費します。 大きなC++の翻訳単位や重いジェネリクスを使うRustクレートが通常のメモリピークであり、大きなバイナリの最終リンクは単一のコンパイルよりも多くのメモリを必要とすることがあります。

メモリ不足で強制終了されたビルドには、より多くのvCPUではなく、より低い-jやCARGO_BUILD_JOBSが必要です。ジョブを増やすとクラッシュが増えるだけです。ビルドキャッシュはVPS自身のディスク（全プランでNVMeストレージ）に置き、古いイメージはdocker image pruneで削除してください。ビジーなランナーはパイプラインが示すよりも早くディスクを満杯にするからです。

ビルドごとに数十ギガバイトのRAMを必要とするモノレポはベアメタルの領域であり、Cobaltfellでは販売していません。データベースを伴うテストスイートには独自のサイジングルールがあり、PostgreSQLがVPS上で必要とするCPUとRAMの量で扱っています。

VPS上のランナーはどのexecutorを使うべきですか？

Docker executorが適切なデフォルトです。GitLabのexecutorガイドによれば、各ビルドにクリーンで分離された環境を提供する一方、Shell executorはビルドごとのクリーンな環境も、ランナーのファイルシステムの保護も提供しません。 Shell、SSH、VirtualBoxのexecutorはメンテナンスモードです。

誰がジョブを開始できるかも同じくらい重要です。フォークからのマージリクエストは自身のコードをVPS上で実行します。GitHubのセキュリティガイドによれば、セルフホステッドランナーはパブリックリポジトリにはほとんど使うべきではなく、同じ理屈が信頼できないプルリクエストを実行するあらゆるCIシステムに当てはまります。

Forgejo、Woodpecker、Jenkins、GitHub Actionsエージェントも同じ方法でサイジングします。重複するジョブを数え、それぞれに固定のスレッドとメモリを割り当てます。各サイズのプラン価格は専用コアVPSのコストはいくらかに掲載しています。