Сколько RAM нужно для GitLab CE

MAATRIX

GitLab CE в Omnibus-сборке — это не один процесс, а десяток: PostgreSQL, Redis, Sidekiq, Puma, Gitaly, Workhorse и встроенный Prometheus впридачу. Официальный минимум — 4 ГБ RAM, и это честная цифра, а не маркетинговая: меньше — gitlab-ctl reconfigure падает уже на этапе миграций базы. Разбираем, куда уходит память по компонентам, и что реально влезает на 4, 8 и 16 ГБ.

Короткий ответ: сколько RAM нужно для GitLab CE

Цифры для сервера, где кроме GitLab CE ничего не крутится, раннер — отдельно.

Главное отличие от Gitea или Gitea-подобных легковесных систем: у GitLab CE высокое базовое потребление даже в простое. У Gitea простаивающий сервис — 150–200 МБ, у GitLab Omnibus — 2–2,5 ГБ ещё до первого пользователя, потому что запущены сразу восемь-десять процессов. Пик от CI и клонирования добавляется поверх этой базы, а не вместо неё.

Из чего состоит Omnibus: восемь процессов вместо одного

GitLab CE ставится либо через Omnibus-пакет (all-in-one, самый частый вариант), либо через docker-compose с тем же образом gitlab/gitlab-ce. Внутри в обоих случаях один и тот же набор служб под управлением runit. Проверьте, что реально запущено:

sudo gitlab-ctl status

run: gitaly: (pid 1842) 3820s
run: gitlab-workhorse: (pid 1855) 3820s
run: logrotate: (pid 1861) 3820s
run: node-exporter: (pid 1867) 3820s
run: postgres-exporter: (pid 1872) 3820s
run: postgresql: (pid 1712) 3830s
run: prometheus: (pid 1880) 3820s
run: puma: (pid 1798) 3825s
run: redis: (pid 1690) 3835s
run: redis-exporter: (pid 1895) 3820s
run: sidekiq: (pid 1811) 3822s

Одиннадцать процессов на пустой инсталляции. Разбивка по памяти для установки без пользователей (замер ps aux --sort=-rss на свежем сервере):

Сумма — 1,9–2,9 ГБ ещё до того, как кто-то открыл страницу проекта. Это и есть причина, по которой 4 ГБ — минимум с оговорками, а не запас: половина памяти уходит на инфраструктуру, вторая половина — на реальную нагрузку.

Puma и Sidekiq: где растёт нагрузка от пользователей

Puma — это веб-сервер на Ruby, и по умолчанию GitLab считает число воркеров от ядер:

sudo cat /etc/gitlab/gitlab.rb | grep -A3 "puma\['worker_processes'\]"

Формула по умолчанию — [количество ядер, 4].min, но не меньше 2. На 2 vCPU получаем 2 воркера, на 8 vCPU — уже 4. Каждый воркер Puma — это отдельный процесс Ruby с собственной копией загруженного приложения: 200–400 МБ на воркер только на старте, и это растёт с трафиком, потому что Ruby не всегда быстро возвращает память ОС обратно.

# /etc/gitlab/gitlab.rb
puma['worker_processes'] = 2
puma['per_worker_max_memory_mb'] = 850

per_worker_max_memory_mb — защита от утечек: воркер, превысивший лимит, перезапускается сам, до того как его убьёт OOM killer вместе с соседними процессами. На малой памяти это дешевле, чем ловить падение всего сервера.

Sidekiq работает иначе — один процесс с пулом потоков (concurrency), а не форк на ядро:

sidekiq['concurrency'] = 10  # по умолчанию 20

На 4 ГБ 20 параллельных Sidekiq-потоков — избыточно: каждый push вызывает десяток фоновых задач (обновление статистики, вебхуки, индексация), и при concurrency = 20 они все стартуют разом, забирая память под свои копии Rails-объектов. Снижение до 10 почти не замедляет обработку очереди на малых командах, но срезает пиковое потребление на 200–400 МБ.

Как отключить лишнее и вернуть память

Встроенный Prometheus с четырьмя exporter'ами полезен на 20+ пользователях, но на маленьком сервере — 250–400 МБ впустую, особенно если вы и так смотрите метрики через внешний Grafana и Prometheus. Отключение — правка /etc/gitlab/gitlab.rb и reconfigure:

prometheus_monitoring['enable'] = false

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Дальше — сервисы, которые ставятся по умолчанию, даже если вы ими не пользуетесь:

# Container Registry — нужен только если храните Docker-образы в GitLab
registry['enable'] = false

# GitLab Pages — статический хостинг из репозиториев, редко используют на малых командах
gitlab_pages['enable'] = false

# Grafana — свой встроенный дашборд, дублирует внешний
grafana['enable'] = false

Отдельно про PostgreSQL внутри Omnibus: она настроена консервативно, но при памяти впритык стоит проверить shared_buffers:

postgresql['shared_buffers'] = "256MB"
postgresql['max_connections'] = 100

Общий принцип тот же, что и для отдельно стоящего PostgreSQL: тюнинг под доступную память даёт больше, чем покупка следующего тарифа, если узкое место — не сама база, а конфигурация по умолчанию.

CI-раннер: считайте память отдельно от сервера GitLab

gitlab-runner — самостоятельный процесс, и почти всегда его стоит выносить на отдельную машину: GitLab CE и так плотно ест память в простое, а job — это ещё один Docker-контейнер поверх. Замеры пиковой памяти для типичных job (executor docker, теги по умолчанию):

Если раннер стоит на одной машине с GitLab CE, ограничьте одновременные job:

# /etc/gitlab-runner/config.toml
[[runners]]
  executor = "docker"
  [runners.docker]
    memory = "1536m"
    memory_swap = "1536m"

concurrent в верхней части config.toml — общий лимит по всем раннерам сразу; на 8 ГБ с самим GitLab CE безопасное значение — 1–2, не больше. Подробная настройка раннера — в отдельной статье про GitLab CI/CD на VPS, а частые сбои раннера разобраны в материале про ошибки GitLab CI Runner.

Как измерить реальное потребление, а не гадать по документации

Сводка по памяти системы:

free -h

Колонка available честнее, чем free: она учитывает страничный кэш, который ядро отдаст под нагрузкой. Если available уходит в ноль при обычной работе — апгрейд неизбежен, а не «настройте получше».

По каждому процессу GitLab:

ps aux --sort=-rss | grep -E 'puma|sidekiq|postgres|gitaly|redis' | awk '{printf "%-10s %6.0f MB  %s\n", $2, $6/1024, $11}'

Пиковое потребление cgroup, если GitLab CE запущен в контейнере (docker-compose):

cat /sys/fs/cgroup/memory.peak

Журнал на предмет OOM:

sudo dmesg -T | grep -iE "out of memory|oom-kill"
sudo journalctl -u gitlab-runsvdir --since "yesterday" | grep -iE "oom|killed"

Строка Out of memory: Killed process (puma: cluster worker) значит, что воркеров слишком много для доступной памяти — снижайте worker_processes, а не только докупайте RAM. Если убит sidekiq — режьте concurrency. Общие рецепты по нехватке памяти на сервере — в статье что делать при нехватке RAM, а по правильному размеру подкачки — в материале про swap для VPS.

Какой сервер взять в MAATRIX под GitLab CE

Честный минимум: 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Отключите встроенный Prometheus и Container Registry, снизьте sidekiq['concurrency'] до 10, добавьте swap на 2 ГБ как страховку от разовых пиков — и получите рабочий сервер для команды из 3–5 человек без CI на той же машине.

Рекомендуемый вариант: 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Это официально советуемая GitLab конфигурация для команд до 20 человек. Здесь можно оставить встроенный Prometheus, держать лёгкий раннер рядом (1 job одновременно) и не думать о лимитах Puma каждую неделю.

Если сборок и пользователей много: 8 vCPU, 16 ГБ RAM, 160 ГБ NVMe. Container Registry, несколько параллельных Sidekiq-задач, запас под git-подпроцессы на больших репозиториях. Раннер лучше выносить на отдельный сервер даже здесь — CI-нагрузка непредсказуема по всплескам, и вы не хотите, чтобы упавший job тянул за собой веб-интерфейс для всей команды.

Если 8 ГБ выглядит избыточно для вашей команды, но GitLab-specific функции (встроенный Container Registry, полноценный CI без сторонних сервисов) не нужны, честно посмотрите на сравнение Gitea и GitLab: Gitea на той же памяти держит в разы больше пользователей, но без части экосистемы GitLab.

GitLab CE из каталога apps.maatrix.io разворачивается автоматически при заказе сервера — Omnibus-пакет ставится и настраивается без ручного apt install, адрес и первичный пароль root приходят в личный кабинет. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT, иностранная карта не требуется даже для серверов в Лондоне или США.

Частые вопросы