GitLab Runner VPS को कितने dedicated vCPU चाहिए?

एक VPS एक साथ कितने CI job चला सकता है?

एक CI job को दो समर्पित vCPU और उनके साथ आने वाली RAM चाहिए; runner की concurrent सेटिंग तय करती है कि ऐसे कितने job VPS साझा करेंगे। config.toml में, concurrent सभी registered runners में job सीमित करता है, और limit एक registered runner के लिए उन्हें सीमित करता है (0, जो डिफ़ॉल्ट है, का मतलब कोई सीमा नहीं)। GitLab का requirements पेज तीन इनपुट बताता है जिनसे साइज़ तय करें: job का CPU load, उनका memory उपयोग और एक साथ कितने चलते हैं।

GitLab के होस्टेड runner साइज़ VPS से कैसे तुलना करते हैं?

GitLab के होस्टेड Linux runners प्रति vCPU 4 GB RAM देते हैं; Cobaltfell प्लान प्रति vCPU 2 GB देते हैं। vCPU की संख्या एक-के-बदले-एक मिलती है, जिससे यह टेबल उन pipelines के लिए साइज़ चुनने का सीधा तरीका बन जाती है जो पहले से GitLab.com पर चलते हैं। जो job अपनी वर्तमान मशीन की ज़्यादातर memory उपयोग करते हैं, उन्हें एक साइज़ ऊपर का Cobaltfell प्लान चाहिए, या एक बार में कम job।

2 November 2026 के Cobaltfell सर्वे के अनुसार, 2022 या बाद के processor पर एक समर्पित vCPU की मासिक लागत उन hosts पर औसतन $8.20 थी जो बिना ID जाँच के crypto लेते हैं, इसलिए दो vCPU के हर समानांतर CI job की लागत लगभग उससे दोगुनी है।

उस औसत के पीछे का हर host और कीमत नवंबर 2026 में प्रति core एक समर्पित CPU VPS की लागत] में है।

CI और compile job के लिए समर्पित cores क्यों मायने रखते हैं?

एक build CPU को मिनटों तक पूरे load पर रखता है, ठीक वही पैटर्न जिसे सीमित करने के लिए shared VPS प्लान लिखे जाते हैं। उसी सर्वे के दो hosts इसे अपने नियमों में लिखते हैं: Spartan Host की शर्तें आवंटित cores के 50% से ज़्यादा एक घंटे से अधिक उपयोग करने की मनाही करती हैं, और Advin Servers की fair-use policy CPU उपयोग को 75% पर सीमित करती है।

shared vCPU पर लागत steal time के रूप में भी दिखती है। जो pipeline शांत रात में तेज़ होती है वह peak hours में खिंच जाती है, और job timeouts ऐसे कारणों से फ़ायर होते हैं जिनका code से कोई संबंध नहीं; CPU steal time क्या है और VPS पर इसे कैसे जाँचें दिखाता है कि इसे कैसे पढ़ें।

Cobaltfell पर: जब तक आपके काम को ज़रूरत हो, पूरा load चलाने की अनुमति है: कोई CPU credit नहीं, कोई burst window नहीं और 100% पर कुछ मिनट बाद कोई throttling नहीं। एक vCPU होस्ट प्रोसेसर का एक हार्डवेयर थ्रेड है। आपके थ्रेड आपके VPS से एक-से-एक पिन किए जाते हैं और कभी किसी दूसरे ग्राहक को नहीं दिए जाते, और एक फ़िज़िकल कोर के दोनों थ्रेड साथ ही रहते हैं, इसलिए हर 2 vCPU एक पूरा कोर बनाते हैं जिसे कोई पड़ोसी साझा नहीं करता। threads पर कोई neighbour न होने से, cache-वार्म pipeline हर बार लगभग उतना ही समय लेती है, इसलिए धीमा job code की ओर इशारा करता है। vCPU-to-core नियम कैसे काम करता है, यह क्या समर्पित vCPU एक core है या thread] में समझाया गया है।

मैं कैसे रोकूँ कि समानांतर builds एक ही vCPU पर लड़ें?

हर job को VPS का तय हिस्सा दें और वही संख्या build tool को भी दें। Build tools के डिफ़ॉल्ट अलग-अलग हैं। GNU make एक बार में एक recipe चलाता है जब तक -j न दिया जाए। Cargo उतने ही job चलाता है जितने logical CPU हैं। Ninja बिना कहे CPU संख्या के आधार पर समानांतर चलता है। Fell 8 पर ऐसे चार builds में से हर एक आठ compilers शुरू करेगा: 8 threads और 16 GB RAM के लिए 32 processes।

Docker executor के साथ, हर job अपने container में चलता है, और [runners.docker] उस container के लिए cpus और memory सीमा लेता है। दोनों सेट करें, फिर job के अंदर parallelism मिलाएँ:

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++ compile करने के लिए VPS पर क्या चाहिए?

Compiles को threads और memory साथ-साथ चाहिए: हर समानांतर compiler process और हर link step RAM का अपना हिस्सा लेता है। बड़े C++ translation units और heavy generics वाले Rust crates आमतौर पर memory peaks हैं, और बड़े binary का अंतिम link किसी भी एक compile से ज़्यादा माँग सकता है।

memory की कमी से मारा गया build कम -j या CARGO_BUILD_JOBS चाहता है, ज़्यादा vCPU नहीं: कम job पूरे होंगे, ज़्यादा job crash होंगे। Build caches VPS की अपनी disk (हर प्लान पर NVMe storage) पर रखें और पुरानी images docker image prune से हटाएँ, क्योंकि व्यस्त runner pipeline के संकेत से तेज़ी से disk भरता है।

जिस monorepo को प्रति build कई दसियों gigabytes RAM चाहिए वह bare-metal का क्षेत्र है, जो Cobaltfell नहीं बेचता। Database-backed test suites के अपने sizing नियम हैं, जो VPS पर PostgreSQL को कितना CPU और RAM चाहिए] में बताए गए हैं।

VPS पर runner को कौन सा executor उपयोग करना चाहिए?

Docker executor सही डिफ़ॉल्ट है: GitLab की executor गाइड कहती है कि यह हर build को साफ़, अलग वातावरण देता है, जबकि Shell executor न तो प्रति build साफ़ वातावरण देता है और न ही runner के file system की सुरक्षा। Shell, SSH और VirtualBox executors maintenance mode में हैं।

कौन job शुरू कर सकता है, यह भी उतना ही मायने रखता है: किसी fork से आया merge request VPS पर उसका अपना code चलाता है। GitHub की security गाइड कहती है कि self-hosted runners का उपयोग public repositories के लिए लगभग कभी नहीं करना चाहिए, और यही तर्क किसी भी CI system पर लागू होता है जो untrusted pull requests चलाता है।

Forgejo, Woodpecker, Jenkins और GitHub Actions agents का साइज़ उसी तरह तय करें: overlapping jobs गिनें, हर एक को तय threads और memory दें। हर साइज़ की प्लान कीमतें समर्पित-core VPS की लागत कितनी है] के अंतर्गत सूचीबद्ध हैं।