это норма, вопрос только сколько там остается после сборки и как часто сборка вызывается

Выше я ответил: автодетект xmx кривой, additionalBuildArgs не работает, только систем проперти

Так у меня без неё на билдсервере не собиралось

Давал 6гб, оом на билдсервере
В локальном докере с 3гб собирается

лимиты сигруппы юзал? )

У меня 9-10 гб точно требует. Приходится всё кроме идеи вырубать при компиляции

На билдсервере там хз что и как юзается ;)

Гитлаб ci

Ехал докер через докер...

над ключи глянуть, возможно просто использовалась вся доступная память сервера

А мультистейдж не пробовали, который кваркус предлагает?

Нет, не вся, но на 4 гигабайтном инстансе он ставил xmx 3.5g

А с учётом что там ещё и мейвен же запущен который этот нейтив имейдж дёргает, и самой jvm на всякие нужды нейтив память нужна

В итоге падала что не может закомитить память на запросе

Пробовали, тоже падал, так как памяти не хватало

Пока параметры явно не проставил на лимиты её

Анализ вселенной делает

😂👍

@lol_dog я ради интереса даже поигрался с созданием разных контейнеров :) и смотрел сколько он памяти проставлял

Всегда где-то было процентов 80

By the way, why does it default to using 80% of the machines physical memory? On my machine, I'm running browsers and slack and all sorts of other stuff, I definitely never have 80% of my physical memory free to do just one thing, so I frequently see my native-image processes being OOM killed by the OS due to this. I don't understand why that default would be chosen, it only makes sense on a dedicated build machine, and even then, build tools (like Maven) that are likely invoking the graal compiler are probably already taking up more than 20% of the available memory.

о, даже правильно я на глаз определял =)

https://github.com/oracle/graal/pull/1591

Assume the user knows what they're doing if they ask for
specific values of Xmx/Xms when invoking native-image.

@vektory79 так что может это и с твоей проблемой тоже может быть связано

-J-Xmx / -J-Xms и посмотреть результат