Сколько RAM нужно для Gitea

MAATRIX

Официальные требования Gitea — 1 ГБ RAM, и это не маркетинг: сам сервис занимает меньше двухсот мегабайт. Падает такой сервер не от веб-интерфейса, а от git pack-objects на клонировании крупного репозитория и от сборки в Actions, которой на пике нужно два гигабайта. Считаем по частям: Gitea, база, git и CI.

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

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

Главное: требования Gitea — это не одна цифра, а две. Постоянное потребление (сервис, база, индексаторы) — сотни мегабайт, и растёт оно медленно. Пик — тяжёлый клон, ночной git fsck, старт job в Actions — живёт минуты и удваивает нагрузку. Сервер умирает на пике, под него и считайте запас. По CPU: интерфейсу хватает ядра, но git gc и pack-objects процессорные, и на 1 vCPU отдача гигабайтного репозитория растянется на минуты.

Куда уходит память: сам сервис, база и индексаторы

Gitea написана на Go и живёт одним бинарником: ни PHP-воркеров, ни JVM. Версию проверьте сразу, от неё зависят ключи конфига: sudo -u git /usr/local/bin/gitea --version даёт Gitea version 1.24.6 built with GNU Make 4.3, go1.24.4 : bindata, sqlite. Живой инстанс: 34 репозитория, 8 пользователей, PostgreSQL рядом, Actions выключены.

● gitea.service - Gitea (Git with a cup of tea)
     Active: active (running) since Mon 2026-08-17 09:12:44 MSK; 1 week 4 days ago
      Tasks: 14 (limit: 4613)
     Memory: 178.4M (peak: 402.1M)

178.4M процесс держит сейчас, peak — худший момент за одиннадцать дней. Разрыв в 2,3 раза нормален, тариф считают по второй цифре; systemd 254 и новее показывает её сам. Прибавьте базу:

Третья статья расхода — индексаторы:

• Поиск по задачам. По умолчанию [indexer] ISSUE_INDEXER_TYPE = bleve, индекс в файле: +40–120 МБ на нескольких тысячах задач. На маленькой машине ставьте db — поиск станет грубее, зато память вернётся.
• Поиск по коду. [indexer] REPO_INDEXER_ENABLED = true выключен по умолчанию, и не зря: bleve-индекс просит 250–400 МБ RSS и занимает на диске столько же, сколько код. Включаете — ограничьте размер файлов: [indexer] MAX_FILE_SIZE = 1048576.
• Elasticsearch. REPO_INDEXER_TYPE = elasticsearch снимает нагрузку с Gitea, но JVM мало 2 ГБ heap. Это отдельная машина, а не строчка в конфиге.

Плюс хост: systemd, sshd, агент мониторинга — 150–250 МБ. Итого «пустая» инсталляция с Postgres укладывается в 500 МБ.

Git-подпроцессы: вот где память кончается

Gitea почти не растёт — растут её дети: на каждый клон, push, дифф и ночную проверку она запускает настоящий git, у которого лимитов по умолчанию нет. Сервер с 1 ГБ, разработчик клонирует репозиторий на 900 МБ и видит:

remote: Enumerating objects: 264117, done.
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: early EOF
fatal: index-pack failed

А на сервере в это время:

sudo dmesg -T | grep -i "killed process"
[Fri Aug 14 03:00:19 2026] Out of memory: Killed process 14428 (git)
total-vm:1876932kB, anon-rss:1439288kB, UID:998, oom_score_adj:0

Убили не gitea, а git pack-objects: он собирает pack на лету, а pack.windowMemory по умолчанию равен нулю — «сколько дадите». Каждый поток берёт своё окно, а потоков столько же, сколько ядер. Лечится конфигом: нужные ключи Gitea пишет в git-конфиг сама, секцией [git.config] в app.ini:

[git.config]
pack.windowMemory = 32m
pack.deltaCacheSize = 64m
pack.threads = 1
core.bigFileThreshold = 8m

pack.windowMemory ограничивает окно дельта-сжатия на поток, pack.threads = 1 убирает умножение на ядра, а core.bigFileThreshold (по умолчанию 512 МБ) велит хранить крупные файлы без дельта-сжатия — на них и уходит память в репозиториях с картинками и бинарями. Честная цена: тот же репозиторий отдавался 48 секунд при pack.threads = 0 и 2 минуты 10 секунд при = 1.

Второй едок — плановые задачи. git fsck из Repository Health Check обходит все репозитории в полночь и на крупном берёт гигабайт. Отсюда падения «ночью, когда никого нет»:

[cron.repo_health_check]
SCHEDULE = @every 168h
TIMEOUT = 300s

И третье: не жмите в рабочее время Run now на задаче Garbage collect all repositories (Site Administration → Monitoring → Cron Tasks) — она проходит git gc по всем репозиториям подряд. Её аргументы берутся из [git] GC_ARGS, и --aggressive там не место ни при какой памяти.

Actions и раннер: где кончаются два гигабайта

Сам сервер задач не выполняет: их берёт act_runner — процесс на 30–60 МБ, поднимающий на каждый job Docker-контейнер. Память уходит в контейнер. Замеры на catthehacker/ubuntu:act-22.04:

Если сборка падает с FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory, а следом в логе job идёт exit code 137 — это не Gitea и не раннер: контейнеру не хватило памяти. Две настройки в config.yaml раннера решают почти всё:

runner:
  capacity: 1
container:
  options: "--memory=2g --memory-swap=2g --cpus=2"

capacity — сколько job раннер берёт одновременно. По умолчанию 1, и поднять до 3 на четырёхгигабайтной машине — прямой путь к OOM: три сборки Node дают 6 ГБ пика. --memory=2g ограничивает контейнер: job умрёт сам, с кодом 137 в своём логе, а не утащит за собой Gitea и базу. Здесь лимит лучше его отсутствия — падение локализовано.

Диск считайте отдельно: образы раннера — 1–3 ГБ, артефакты хранятся по умолчанию 90 дней ([actions] ARTIFACT_RETENTION_DAYS). На 20-гигабайтном диске CI живёт месяц-полтора. Если Actions вообще не стартуют — это другая история.

Как ужать Gitea до одного гигабайта

Рабочая конфигурация для двух-трёх человек, /etc/gitea/app.ini (в Docker — /data/gitea/conf/app.ini):

[indexer]
ISSUE_INDEXER_TYPE = db
REPO_INDEXER_ENABLED = false

[database]
MAX_OPEN_CONNS = 10
MAX_IDLE_CONNS = 2

[git]
MAX_GIT_DIFF_LINES = 500
MAX_GIT_DIFF_FILES = 50

MAX_GIT_DIFF_* — не про красоту интерфейса: открытый в браузере дифф на двадцать тысяч строк разворачивается в памяти целиком.

Второй приём, про который почти не пишут, — GOMEMLIMIT: мягкий лимит, у которого сборщик мусора Go работает агрессивнее вместо того, чтобы дать процессу расти. Через sudo systemctl edit gitea:

[Service]
Environment=GOMEMLIMIT=600MiB
Environment=GOGC=50

Честное ограничение: GOMEMLIMIT управляет только кучей Go, то есть самой Gitea. На git pack-objects он не действует вообще — а это, как мы выяснили, главный едок. Плата — чуть выше загрузка CPU на GC.

Swap-файл на 2 ГБ — страховка от разового пика: sudo fallocate -l 2G /swapfile, chmod 600, mkswap, swapon, строка /swapfile none swap sw 0 0 в /etc/fstab и vm.swappiness=10. Что он даёт честно: ночной git fsck и одиночный тяжёлый клон переживут. Чего не даёт — ёмкости: NVMe в десятки раз медленнее памяти, и Gitea из свопа отвечает не за 80 мс, а за секунды. zram (apt install zram-tools, ALGO=zstd) помогает хуже обычного — git оперирует уже сжатыми объектами, коэффициент выходит 1,2–1,4 вместо трёх-четырёх. Чего на 1 ГБ не будет: Actions на этой же машине, поиска по коду и спокойной работы с LFS.

Как измерить свои требования к памяти и не гадать

Пик из cgroup. Ядро считает его само:

cat /sys/fs/cgroup/system.slice/gitea.service/memory.peak
grep -E '^(anon|file) ' /sys/fs/cgroup/system.slice/gitea.service/memory.stat

memory.peak — максимум за время жизни юнита, в байтах; с тарифом сравнивайте именно его. Строка anon в memory.stat — реальная память процессов, file — отдаваемый кэш. Важная деталь: git-подпроцессы попадают в тот же cgroup, поэтому пик учитывает и клоны.

Встроенные метрики. Включаются в app.ini секцией [metrics]: ENABLED = true и случайный TOKEN.

curl -s -H "Authorization: Bearer $TOKEN" http://127.0.0.1:3000/metrics \
  | grep -E 'process_resident_memory_bytes|go_memstats_heap_inuse_bytes'

Эндпоинт держите на локальном адресе: ufw allow 22/tcp, ufw allow 443/tcp, ufw deny 3000/tcp — через Nginx порт 3000 наружу не нужен.

Журнал. Что смотреть после ночного падения:

journalctl -u gitea --since "yesterday" | grep -iE "oom|signal|panic"
sudo dmesg -T | grep -iE "out of memory|oom-kill"

Строка gitea.service: A process of this unit has been killed by the OOM killer. значит, что памяти не хватило сервису. Если в dmesg убит процесс git — виноват подпроцесс, и лечится это секцией [git.config], а не апгрейдом тарифа.

Порядок: снимите memory.peak через неделю работы, прибавьте пик самого тяжёлого job и 20% — это ваша цифра. Другие поломки — в частых ошибках Gitea.

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

Честный минимум: 1 vCPU, 2 ГБ RAM, 40 ГБ NVMe. Не один гигабайт, хотя документация проекта пишет: «2 CPU cores and 1GB RAM is typically sufficient for small teams/projects». Она описывает сервис, а вы покупаете сервер целиком — плюс база, пик на клонировании и место под репозитории. На 2 ГБ живёт команда из 5–10 человек с PostgreSQL, зеркалами и LFS. Actions здесь не запускайте.

Комфортный вариант: 2 vCPU, 4 ГБ RAM, 80 ГБ NVMe. Gitea, PostgreSQL, act_runner с capacity: 1 и лимитом --memory=2g на job. Помещается ежедневная сборка Node или Go и запас на ночные задачи. Эту конфигурацию советуем чаще всего.

Если сборок много: 4 vCPU, 8 ГБ, 160 ГБ NVMe. Два-три параллельных job, поиск по коду, реестр пакетов и образов. Дешевле — Gitea на маленькой машине, раннер на отдельной: он ходит к ней по HTTPS и рядом быть не обязан.

Локация — Лондон. Причина практическая: CI постоянно ходит наружу — образы с Docker Hub и ghcr.io, пакеты npm и PyPI, Go-модули через proxy.golang.org, экшены и зеркала с GitHub. С британского адреса это тянется напрямую; с российских часть реестров отвечает через раз, и чинить вы будете не память, а failed to fetch. Пинг Москва — Лондон 45–60 мс — для git это как локальная сеть. Франция — та же Европа и GDPR; Россию берут, когда вся команда в РФ, внешних зеркал нет, а данные должны лежать по 152-ФЗ.

Gitea из каталога apps.maatrix.io ставится на сервер автоматически при заказе — вставлять команды не нужно. Автоустановка работает на Ubuntu и Debian, а адрес, логин и пароль появляются в личном кабинете, в разделе «Доступ»; дальше вы правите app.ini под свои цифры. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна даже для лондонской площадки.

Сомневаетесь между 2 и 4 ГБ — критерий один: нужен ли CI на этой же машине; нужен — четыре. Смежное: Gitea против GitLab и установка Gitea на VPS.

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