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

Поставила gitlab runner на тот же vps, где крутится прод «чтоб не плодить серверы». Первый же тяжёлый пайплайн (сборка образа + тесты) сожрал память, oom пришёл и убил, конечно, не runner, а приложение. Классика жанра: сэкономила на втором сервере — уронила прод в разгар дня.
Вылечила пока лимитами: runner в docker executor с mem_limit и cpus, плюс concurrent = 1, чтоб не запускал три джобы разом. Но чувствую, что это костыль. Кто держит runner рядом с продом — вы лимитами обходитесь или всё же выносите сборку на отдельный дешёвый инстанс? На чистой совести хочется второй, но andryukha сейчас придёт считать)

kate_ekb runner рядом с продом — это «пока не собралось что-то тяжёлое». лимиты правильные, но принцип простой: то, что периодически жрёт всё, не должно жить на одном диске и в одной памяти с тем, что должно работать всегда. отдельный дешёвый инстанс под сборку дешевле одного упавшего среди дня прода. concurrent=1 держи, но второй сервер — это не роскошь, это разделение рисков.

kate_ekb у меня даже мысли не было что runner может прод уронить, я думал докер их изолирует) буду знать, что mem_limit это не «на всякий», а прям обязательно. а concurrent где ставится, в config.toml раннера?

max_nn да, в config.toml, concurrent на верхнем уровне и [runners.docker] с memory/cpus. докер изолирует процессы, но память общая физически — если не поставил лимит, джоба сожрёт сколько дотянется и oom выберет жертву, обычно самую жирную, то есть твой прод. nesterov прав, я склоняюсь ко второму инстансу под сборку, лимиты это чтоб прямо сейчас не падало.

kate_ekb звал — пришёл считать) второй инстанс под сборку это Ba Lite за 8$, если сборки не монстры. один упавший прод среди дня по нервам и по клиенту дороже восьми долларов в месяц, тут даже я, скупой, за второй сервер. держать runner на проде ради экономии — это экономия, которая один раз в квартал сжирает весь свой смысл. посчитай простой прода в деньгах, сразу видно.