GitLab Runner VPS ต้องใช้ dedicated vCPU กี่ตัว?

VPS หนึ่งเครื่องรัน CI job พร้อมกันได้กี่ job?

หนึ่ง CI job ต้องใช้ 2 vCPU แบบเฉพาะและ RAM ที่มาคู่กัน; การตั้งค่า concurrent ของ runner เป็นตัวกำหนดว่าจะมี job แบบนี้กี่ตัวแชร์ VPS เครื่องเดียวกัน ใน config.toml, concurrent จำกัดจำนวน job ข้าม runner ที่ลงทะเบียนไว้ทั้งหมด และ limit จำกัดจำนวน job สำหรับ runner ที่ลงทะเบียนไว้หนึ่งตัว (0 ซึ่งเป็นค่า default หมายถึงไม่จำกัด) หน้าข้อกำหนดของ GitLab ระบุปัจจัยสามอย่างที่ใช้กำหนดขนาด: CPU load ของ job, การใช้หน่วยความจำ และจำนวน job ที่รันพร้อมกัน

ขนาด hosted runner ของ GitLab เทียบกับ VPS เป็นอย่างไร?

GitLab hosted Linux runner ให้ RAM 4 GB ต่อ vCPU; แพ็ก Cobaltfell ให้ 2 GB ต่อ vCPU จำนวน vCPU ตรงกันแบบหนึ่งต่อหนึ่ง ทำให้ตารางนี้เป็นวิธีตรงไปตรงมาในการเลือกขนาดสำหรับ pipeline ที่รันบน GitLab.com อยู่แล้ว job ที่ใช้หน่วยความจำเกือบทั้งหมดของเครื่องปัจจุบันต้องใช้แพ็ก Cobaltfell ที่ใหญ่ขึ้นหนึ่งขั้น หรือลดจำนวน job ที่รันพร้อมกัน

ตามการสำรวจของ Cobaltfell เมื่อวันที่ 2 พฤศจิกายน 2026 vCPU แบบเฉพาะหนึ่งตัวบนโปรเซสเซอร์รุ่นปี 2022 หรือใหม่กว่า มีราคามัธยฐาน $8.20 ต่อเดือนที่โฮสต์ที่รับคริปโตโดยไม่ต้องตรวจ ID ดังนั้นแต่ละ CI job แบบขนานที่ใช้ 2 vCPU จึงมีค่าใช้จ่ายประมาณสองเท่าของจำนวนนั้น

โฮสต์และราคาทุกแห่งที่อยู่เบื้องหลังค่ามัธยฐานนั้นอยู่ใน ราคา VPS แบบ dedicated CPU ต่อหนึ่งคอร์ในเดือนพฤศจิกายน 2026

ทำไม core แบบเฉพาะจึงสำคัญสำหรับ CI และงาน compile?

build จะครอง CPU ที่ full load ติดต่อกันหลายนาที ซึ่งเป็นรูปแบบเดียวกับที่แพ็ก VPS แบบ shared ถูกออกแบบมาให้จำกัด โฮสต์สองแห่งในการสำรวจเดียวกันระบุไว้ในกฎ: ข้อกำหนดของ Spartan Host ห้ามใช้ core ที่จัดสรรเกิน 50% ติดต่อกันนานกว่าหนึ่งชั่วโมง และนโยบาย fair-use ของ Advin Servers จำกัดการใช้ CPU ไว้ที่ 75%

บน vCPU แบบ shared ค่าใช้จ่ายยังปรากฏเป็น steal time pipeline ที่เร็วในคืนที่เงียบจะช้าลงในช่วง peak และ job timeout เกิดขึ้นด้วยเหตุผลที่ไม่เกี่ยวข้องกับโค้ด; steal time ของ CPU คืออะไรและตรวจสอบบน VPS ได้อย่างไร อธิบายวิธีอ่านค่านี้

ที่ Cobaltfell: ใช้โหลดเต็มที่ได้ตลอดตราบเท่าที่งานของคุณต้องการ: ไม่มี CPU credit ไม่มีช่วง burst และไม่มีการ throttling หลังจากใช้งานที่ 100% ไปสักพัก vCPU หนึ่งตัวคือหนึ่ง hardware thread ของโปรเซสเซอร์โฮสต์ vCPU ของคุณถูก pin แบบหนึ่งต่อหนึ่งเข้ากับ VPS ของคุณและไม่ถูกให้เช่าต่อให้ลูกค้ารายอื่น และสอง thread ของ physical core หนึ่งตัวจะอยู่ด้วยกันเสมอ ดังนั้นทุก 2 vCPU จึงรวมเป็นหนึ่ง whole core ที่ไม่มีเพื่อนบ้านมาแชร์ เมื่อไม่มีเพื่อนบ้านบน thread เดียวกัน pipeline ที่ cache อุ่นอยู่จะใช้เวลาใกล้เคียงกันทุกครั้งที่รัน ดังนั้น job ที่ช้าจึงชี้ไปที่โค้ด กฎ vCPU ต่อ core ทำงานอย่างไรอธิบายไว้ใน vCPU แบบเฉพาะคือ core หรือ thread

จะหยุดไม่ให้ build แบบขนานแย่ง vCPU ตัวเดียวกันได้อย่างไร?

กำหนดสัดส่วน vCPU ที่แน่นอนให้แต่ละ job และส่งจำนวนเดียวกันไปให้ build tool build tool แต่ละตัวมีค่า default ไม่ตรงกัน GNU make รันหนึ่ง recipe ต่อครั้งเว้นแต่จะระบุ -j Cargo รัน job เท่าจำนวน logical CPU Ninja รันแบบขนานตามจำนวน CPU โดยไม่ต้องสั่ง build สี่ตัวแบบนี้บน Fell 8 จะเริ่ม compiler ตัวละแปด: 32 process สำหรับ 8 thread และ RAM 16 GB

เมื่อใช้ Docker executor แต่ละ job รันใน container ของตัวเอง และ [runners.docker] รับขีดจำกัด cpus และ memory สำหรับ container นั้น ตั้งทั้งสองค่า แล้วจับคู่ parallelism ภายใน job:

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

การ compile Rust หรือ C++ ต้องใช้อะไรบน VPS?

การ compile ต้องมี thread และหน่วยความจำที่สอดคล้องกัน: compiler process แบบขนานทุกตัวและขั้นตอน link ทุกขั้นใช้ RAM ในส่วนของตัวเอง translation unit ของ C++ ขนาดใหญ่และ crate ของ Rust ที่ใช้ generic หนัก ๆ คือจุดที่ใช้หน่วยความจำสูงสุดตามปกติ และการ link ขั้นสุดท้ายของ binary ขนาดใหญ่อาจต้องใช้มากกว่า compile ทีละไฟล์ใด ๆ

build ที่ถูก kill เพราะหน่วยความจำไม่พอต้องใช้ -j หรือ CARGO_BUILD_JOBS ที่ต่ำลง ไม่ใช่ vCPU เพิ่ม: job ที่เสร็จน้อยลง แต่ job ที่ crash มากขึ้น เก็บ build cache ไว้บนดิสก์ของ VPS เอง (ที่เก็บข้อมูล NVMe ในทุกแพ็กเกจ) และลบ image เก่าด้วย docker image prune เพราะ runner ที่ใช้งานหนักจะเต็มดิสก์เร็วกว่าที่ pipeline บ่งบอก

monorepo ที่ต้องใช้ RAM หลายสิบ GB ต่อ build หนึ่งครั้งอยู่ในอาณาเขต bare-metal ซึ่ง Cobaltfell ไม่ได้ขาย ชุดทดสอบที่พึ่ง database มีกฎการกำหนดขนาดของตัวเอง ครอบคลุมใน PostgreSQL ต้องใช้ CPU และ RAM เท่าไรบน VPS

runner บน VPS ควรใช้ executor ตัวไหน?

Docker executor คือค่า default ที่ถูกต้อง: คู่มือ executor ของ GitLab ระบุว่าให้สภาพแวดล้อมที่สะอาดและแยกจากกันสำหรับแต่ละ build ขณะที่ Shell executor ไม่ให้ทั้งสภาพแวดล้อมที่สะอาดต่อ build และการปกป้องระบบไฟล์ของ runner executor แบบ Shell, SSH และ VirtualBox อยู่ในโหมด maintenance

ใครสามารถเริ่ม job ได้ก็สำคัญพอ ๆ กัน: merge request จาก fork รันโค้ดของตัวเองบน VPS คู่มือความปลอดภัยของ GitHub ระบุว่า self-hosted runner ควรแทบจะไม่ถูกใช้กับ repository สาธารณะ และเหตุผลเดียวกันใช้ได้กับระบบ CI ใด ๆ ที่รัน pull request ที่ไม่น่าเชื่อถือ

Forgejo, Woodpecker, Jenkins และ agent ของ GitHub Actions กำหนดขนาดด้วยวิธีเดียวกัน: นับ job ที่ทับซ้อนกัน ให้ thread และหน่วยความจำที่แน่นอนแก่แต่ละตัว ราคาแพ็กสำหรับแต่ละขนาดแสดงอยู่ใน VPS แบบ dedicated-core ราคาเท่าไร