Сообщество / DevOps

gitlab runner на том же сервере где прод, сборка съела всю память

kate_ekb
Junior
Сообщения: 70
Репутация: 39
Дата регистрации:
12.08.2026
АВТОР ТЕМЫ17 сент. 2026 г., 20:15 (GMT+3)
Поставила gitlab runner на тот же vps, где крутится прод «чтоб не плодить серверы». Первый же тяжёлый пайплайн (сборка образа + тесты) сожрал память, oom пришёл и убил, конечно, не runner, а приложение. Классика жанра: сэкономила на втором сервере — уронила прод в разгар дня.
Вылечила пока лимитами: runner в docker executor с mem_limit и cpus, плюс concurrent = 1, чтоб не запускал три джобы разом. Но чувствую, что это костыль. Кто держит runner рядом с продом — вы лимитами обходитесь или всё же выносите сборку на отдельный дешёвый инстанс? На чистой совести хочется второй, но andryukha сейчас придёт считать)
1
nesterov
Junior
Сообщения: 25
Репутация: 20
Дата регистрации:
08.08.2026
17 сент. 2026 г., 21:40 (GMT+3)
kate_ekb runner рядом с продом — это «пока не собралось что-то тяжёлое». лимиты правильные, но принцип простой: то, что периодически жрёт всё, не должно жить на одном диске и в одной памяти с тем, что должно работать всегда. отдельный дешёвый инстанс под сборку дешевле одного упавшего среди дня прода. concurrent=1 держи, но второй сервер — это не роскошь, это разделение рисков.
0
M
max_nn
Junior
Сообщения: 9
Репутация: 3
Дата регистрации:
09.09.2026
17 сент. 2026 г., 22:05 (GMT+3)
kate_ekb у меня даже мысли не было что runner может прод уронить, я думал докер их изолирует) буду знать, что mem_limit это не «на всякий», а прям обязательно. а concurrent где ставится, в config.toml раннера?
0
lexa92
Junior
Сообщения: 94
Репутация: 58
Дата регистрации:
09.08.2026
18 сент. 2026 г., 08:40 (GMT+3)
kate_ekb runner на отдельном инстансе — правильно, но если прям жаба душит второй сервер, минимум вынеси сборку в docker executor с жёстким лимитом и nice/ionice, чтоб она не отжирала io у прода. я так временно жил, пока не завёл отдельный. но временно = «до первого тяжёлого пайплайна», ты это уже поймала.
0
kate_ekb
Junior
Сообщения: 70
Репутация: 39
Дата регистрации:
12.08.2026
18 сент. 2026 г., 09:20 (GMT+3)
max_nn да, в config.toml, concurrent на верхнем уровне и [runners.docker] с memory/cpus. докер изолирует процессы, но память общая физически — если не поставил лимит, джоба сожрёт сколько дотянется и oom выберет жертву, обычно самую жирную, то есть твой прод. nesterov прав, я склоняюсь ко второму инстансу под сборку, лимиты это чтоб прямо сейчас не падало.
1
kate_ekb
Junior
Сообщения: 70
Репутация: 39
Дата регистрации:
12.08.2026
18 сент. 2026 г., 09:50 (GMT+3)
lexa92 да, я в итоге за отдельный Ba Lite под сборку, andryukha меня цифрой добил — простой прода дороже. на проде оставила только деплой-шаг, он лёгкий. mem_limit и nice это подпорки, а разнести — решение. спасибо, что подтвердил, а то жаба реально была.
0
andryukha
Junior
Сообщения: 62
Репутация: 39
Дата регистрации:
17.08.2026
18 сент. 2026 г., 18:50 (GMT+3)
kate_ekb звал — пришёл считать) второй инстанс под сборку это Ba Lite за 8$, если сборки не монстры. один упавший прод среди дня по нервам и по клиенту дороже восьми долларов в месяц, тут даже я, скупой, за второй сервер. держать runner на проде ради экономии — это экономия, которая один раз в квартал сжирает весь свой смысл. посчитай простой прода в деньгах, сразу видно.
1
nesterov
Junior
Сообщения: 25
Репутация: 20
Дата регистрации:
08.08.2026
19 сент. 2026 г., 20:50 (GMT+3)
kate_ekb и артефакты сборки не копи на runner'е бесконечно — они забьют диск тише, чем oom, но так же надёжно. ротация артефактов в gitlab и чистка кэша по расписанию. видел, как runner встал не от нагрузки, а просто от забитого диска старыми сборками.
0