Next 16 в докере жрет всю память на билде, CI падает с кодом 137
Рейтинг: 52.3% · 11 голосов
Войдите, чтобы голосовать
Голосовать «За» и «Против» могут только авторизованные пользователи. Войдите в свой аккаунт — или зарегистрируйтесь, это займёт минуту.
Нет аккаунта? Зарегистрироваться
Next 16 в докере жрет всю память на билде, CI падает с кодом 137
Обновились с Next 15.3 на 16, и теперь сборка в GitLab CI стабильно умирает с exit code 137. Раннер на 4 гб, докер, нода 24. Проект средний, app router, около 120 страниц, половина статика через generateStaticParams. Локально на маке с 32 гб собирается минуты за полторы и все ок.
Пробовал NODE_OPTIONS=-max-old-space-size=3072, не помогло вообще. Отключал sourcemaps, стало чуть лучше, но падает через раз. До апгрейда на вебпаке годами жило на тех же раннерах.
Кто-нибудь уже воевал? Откатывать 16 не хочется, нам там нужен новый кеш.
Пробовал NODE_OPTIONS=-max-old-space-size=3072, не помогло вообще. Отключал sourcemaps, стало чуть лучше, но падает через раз. До апгрейда на вебпаке годами жило на тех же раннерах.
Кто-нибудь уже воевал? Откатывать 16 не хочется, нам там нужен новый кеш.
✔ Лучший ответ сформирован автоматически — qcdeed
У нас похожий сетап, лечили так: 1. multi-stage: стадия build уезжает на жирный раннер (отдельный тег с 8gb), финальный образ собирается из standalone, он мелкий 2. кеш .next/cache между пайплайнами через ci cache, без него turbopack каждый раз строит мир с нуля 3. NEXT_TELEMETRY_DISABLED=1, мелочь, но память чуть ровнее И проверьте concurrent у гитлаб-раннера. Он по дефолту может посадить два дж…
Re: Next 16 в докере жрет всю память на билде, CI падает с кодом 137
max-old-space-size тут и не должен помогать. Turbopack это раст, ему лимиты кучи v8 по барабану. Он держит весь граф модулей в памяти, на наших ~300 страницах ел 6 с лишним гигов на пике. Мы в итоге вернули вебпак, в 16 он еще живой, хоть и помечен deprecated. Собирается процентов на 40 дольше, зато влезает в 4 гб и не лотерея.
Re: Next 16 в докере жрет всю память на билде, CI падает с кодом 137
✔ Лучший ответ — сформирован автоматически
У нас похожий сетап, лечили так:
1. multi-stage: стадия build уезжает на жирный раннер (отдельный тег с 8gb), финальный образ собирается из standalone, он мелкий
2. кеш .next/cache между пайплайнами через ci cache, без него turbopack каждый раз строит мир с нуля
3. NEXT_TELEMETRY_DISABLED=1, мелочь, но память чуть ровнее
И проверьте concurrent у гитлаб-раннера. Он по дефолту может посадить два джоба на одну машину, вот вам и oom при формально достаточной памяти.
1. multi-stage: стадия build уезжает на жирный раннер (отдельный тег с 8gb), финальный образ собирается из standalone, он мелкий
2. кеш .next/cache между пайплайнами через ci cache, без него turbopack каждый раз строит мир с нуля
3. NEXT_TELEMETRY_DISABLED=1, мелочь, но память чуть ровнее
И проверьте concurrent у гитлаб-раннера. Он по дефолту может посадить два джоба на одну машину, вот вам и oom при формально достаточной памяти.
Поделиться темой:
✈ Telegram
VK
- Похожие темы
-
- ZFS ARC сожрал всю память, OOM killer прибил VM посреди ночи. Как приручить?
21 ответов · 1636 просмотров
-
- *arr-стек на сидбоксе через gluetun: VPN падает — и весь docker-стек встаёт колом
14 ответов · 948 просмотров
-
-
-
-
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей