منابع موردنیاز سرور GitLab؛ راهنمای انتخاب CPU، RAM و فضای ذخیره‌سازی

منابع موردنیاز GitLab را نمی‌توان فقط با تعداد کاربران تعیین کرد. فعالیت Git، تعداد Pipelineها، Jobهای هم‌زمان، اسکن‌های امنیتی و حجم Artifact و Registry مشخص می‌کنند که سرور به چه مقدار CPU، RAM و فضای ذخیره‌سازی نیاز دارد.

طبق راهنمای رسمی نصب GitLab، مبنای فعلی برای نصب تک‌گره‌ای استاندارد ۸ vCPU و ۱۶GB RAM است. GitLab برای محیط تک‌گره‌ای محدود، امکان اجرا با دست‌کم ۸GB RAM را نیز ذکر می‌کند؛ اما این عدد به معنی ظرفیت مناسب برای هر تیم و هر Pipeline نیست.

پاسخ عملی این است: از Baseline رسمی شروع کنید، Runner را جداگانه اندازه بگیرید و پس از راه‌اندازی، مصرف واقعی را زیر بار کاری تیم اندازه‌گیری کنید.

چرا یک عدد ثابت برای همه تیم‌ها وجود ندارد؟

دو تیم با ده کاربر می‌توانند مصرف کاملاً متفاوتی داشته باشند. یک تیم فقط Repository را نگه می‌دارد و روزانه چند Push انجام می‌دهد؛ تیم دیگر هم‌زمان Build، تست E2E، SAST، Container Scan و انتشار Artifact را اجرا می‌کند. در سناریوی دوم، فشار اصلی ممکن است از سمت Runner و ذخیره‌سازی ایجاد شود، نه از تعداد حساب‌های کاربری.

آیا ۲ هسته و ۴GB RAM برای GitLab کافی است؟

چنین سروری ممکن است در یک آزمایش یا محیط بسیار کوچک بالا بیاید، اما «اجراشدن» با «ظرفیت مناسب برای سرویس پایدار» یکسان نیست. GitLab از چند جزء مانند Rails، Sidekiq، PostgreSQL، Redis یا Valkey و Gitaly تشکیل می‌شود. با فعال‌شدن Pipeline، Registry، اسکن امنیتی و مانیتورینگ، مصرف منابع بیشتر می‌شود.

راهنمای محیط کم‌منبع GitLab سناریویی ویژه برای حداکثر پنج توسعه‌دهنده و Repositoryهای کوچک‌تر از ۱۰۰MB ارائه می‌کند. مقادیر پایین این راهنما به تنظیمات خاص، Swap و پذیرش افت احتمالی عملکرد وابسته‌اند و نباید به‌عنوان حداقل استاندارد خرید معرفی شوند.

CPU سرور GitLab را بر چه اساسی انتخاب کنیم؟

درخواست‌های وب، عملیات Git، Jobهای پس‌زمینه و دسترسی به Repository همگی CPU مصرف می‌کنند. اگر Jobهای CI روی همان ماشین اجرا شوند، Build یا تست سنگین می‌تواند CPU را ناگهان اشباع کند.

پیش از انتخاب پلن، این پرسش‌ها را پاسخ دهید:

• چند کاربر هم‌زمان دارید؟
• روزانه چند Push و Merge Request انجام می‌شود؟
• چند Job باید هم‌زمان اجرا شود؟
• Build پروژه چقدر CPU مصرف می‌کند؟
• آیا SAST، Container Scan یا تست E2E دارید؟

اگر مشکل اصلی، ماندن Jobها در صف است، افزایش CPU سرور اصلی GitLab همیشه راه‌حل درست نیست؛ ممکن است Runner گلوگاه باشد.

RAM چه نقشی در پایداری GitLab دارد؟

کمبود RAM می‌تواند باعث Swap، افت پاسخ‌گویی و ناپایداری شود. راهنمای رسمی GitLab هشدار می‌دهد که Swap زیر بار می‌تواند عملکرد را به‌شدت کاهش دهد. در محیط کم‌منبع ممکن است Swap بخشی از طراحی باشد، اما آن حالت یک استثنا برای تیم بسیار کوچک است.

پس از راه‌اندازی، میانگین و اوج مصرف RAM را در ساعت‌های کاری ثبت کنید. اندازه‌گیری باید روزهایی را هم پوشش دهد که Pipeline و اسکن امنیتی اجرا می‌شوند.

فضای Disk موردنیاز GitLab را چگونه حساب کنیم؟

فقط حجم فعلی سورس‌کد را در نظر نگیرید. فضای لازم شامل سیستم‌عامل و بسته‌های GitLab، Repository و تاریخچه Git، PostgreSQL، Git LFS، Artifactها، Job Logها، Container Registry، Uploadها، Packageها و فایل‌های Backup است.

در مستند رسمی، برای Application Node حداقل ۴۰GB فضای پایه ذکر شده است؛ فضای Repository و Database جداگانه به آن اضافه می‌شود. GitLab برای عملکرد بهتر، به‌ویژه برای Gitaly، ذخیره‌سازی مبتنی بر SSD را توصیه می‌کند.

برای خرید عملی، حجم فعلی داده را با نرخ رشد هفتگی یا ماهانه جمع کنید، سیاست نگهداری Artifact و Registry را مشخص کنید و فضای آزاد کافی برای Upgrade، Backup و عملیات نگهداری کنار بگذارید.

Runner روی همان سرور باشد یا جداگانه؟

Runner روی همان سرور

برای آزمایش و Jobهای سبک ساده‌تر است، اما Build یا تست سنگین می‌تواند CPU، RAM و Disk I/O را از خود GitLab بگیرد و رابط کاربری یا عملیات Repository را کند کند.

Runner جداگانه

برای تیمی که Pipeline متعدد یا Jobهای سنگین دارد، Runner جداگانه انتخاب قابل‌کنترل‌تری است. در این حالت می‌توانید تعداد Runnerها را مستقل افزایش دهید، Executor مناسب انتخاب کنید و اجرای کد پروژه را از سرور Repository دور نگه دارید.

از نظر امنیتی نیز Runner کد تعریف‌شده در Job را اجرا می‌کند. راهنمای امنیت Runnerهای Self-managed درباره خطرهای Runner اشتراکی، Shell Executor و اجرای Privileged توضیح می‌دهد. Runner باید با جداسازی مناسب، Token محدود و سیاست دسترسی روشن مدیریت شود.

اثر AI Coding بر منابع GitLab چیست؟

خود مدل هوش مصنوعی الزاماً روی سرور GitLab اجرا نمی‌شود، اما AI Coding می‌تواند تعداد Commit، Merge Request و Pipeline را افزایش دهد. بنابراین اندازه‌گذاری را فقط بر اساس تعداد اعضای تیم انجام ندهید.

این شاخص‌ها تصویر دقیق‌تری می‌دهند:

• تعداد Pipeline در روز؛
• تعداد Job هم‌زمان؛
• زمان متوسط هر Job؛
• حجم Artifact تولیدشده؛
• رشد هفتگی Repository و Registry؛
• درصد استفاده CPU و RAM در اوج؛
• زمان انتظار Job در صف Runner.

چه زمانی منابع GitLab را ارتقا دهیم؟

• رابط GitLab هنگام اجرای Pipeline کند می‌شود.
• Jobها مدت زیادی در صف می‌مانند.
• RAM دائماً نزدیک سقف است یا Swap فعال می‌شود.
• Disk I/O به گلوگاه تبدیل شده است.
• فضای آزاد به محدوده خطر نزدیک شده است.
• Backup یا Upgrade به‌دلیل کمبود فضا شکست می‌خورد.
• زمان Clone، Push یا بازشدن Merge Request به‌طور محسوس افزایش یافته است.

پیشنهاد عملی برای انتخاب پلن

1. مشخص کنید GitLab فقط Repository است یا CI/CD را هم اجرا می‌کند.
2. Baseline رسمی نسخه فعلی GitLab را بررسی کنید.
3. منابع Runner را جداگانه اندازه‌گذاری کنید.
4. برای Disk، نرخ رشد و سیاست نگهداری Artifact و Registry تعریف کنید.
5. پلنی انتخاب کنید که ارتقای CPU، RAM و Disk در آن ممکن باشد.
6. پس از دو تا چهار هفته، اندازه واقعی را با داده مصرف بازبینی کنید.

برای اجرای سرویس، ابتدا آموزش راه‌اندازی GitLab در آرانیک را ببینید و سپس از صفحه GitLab در آرانیک پلن مناسب را انتخاب کنید.

پرسش‌های متداول

آیا GitLab با ۸GB RAM اجرا می‌شود؟

راهنمای رسمی GitLab این مقدار را برای نصب تک‌گره‌ای محدود ذکر می‌کند؛ اما Workload و قابلیت‌های فعال تعیین می‌کنند تجربه پایدار باشد یا نه. Baseline نصب استاندارد ۱۶GB RAM است.

چقدر فضای Disk برای GitLab لازم است؟

حداقل پایه نصب کافی نیست. حجم Repository، Artifact، Registry، Database، Backup و رشد آینده را با هم جمع کنید و فضای آزاد عملیاتی نگه دارید.

آیا افزایش منابع سرور GitLab صف Pipeline را حل می‌کند؟

فقط وقتی Jobها روی همان سرور اجرا شوند یا خود GitLab گلوگاه باشد. اگر Runner ظرفیت کافی ندارد، باید منابع یا تعداد Runnerها افزایش پیدا کند.

جمع‌بندی

برای یک نصب تک‌گره‌ای استاندارد، ۸ vCPU و ۱۶GB RAM مبنای فعلی GitLab است، نه نسخه قطعی برای همه تیم‌ها. ظرفیت درست باید با حجم Repository، تعداد Pipeline، Jobهای هم‌زمان، Artifact، Registry و نرخ رشد داده تنظیم شود. در تیم‌های دارای CI/CD فعال، جداسازی Runner معمولاً کنترل‌پذیری و مقیاس‌پذیری بیشتری ایجاد می‌کند.