Java-buildpack: Не удается запустить приложение Java с версией пакета сборки b08a692

Подтвержденный. Мы также видим эту проблему,

Пожалуйста, не могли бы вы опубликовать точную ошибку из журналов приложений.

Калькулятор памяти пакета сборки Java был обновлен до версии 3 путем фиксации b08a692. v3 учитывает значения по умолчанию OpenJDK для зарезервированного кеша кода, который в Java 8 составляет 240 мегабайт. Вполне вероятно, что это причина того, что приложение не запускается. Вы можете переопределить значение, используемое калькулятором памяти, как в следующем примере:

cf set-env app-name JAVA_OPTS '-XX:ReservedCodeCacheSize=64m'

но вам придется выбрать подходящий размер, потому что, если вы сделаете его слишком маленьким, потребление ЦП приложением может стать высоким.

Из-за фиксации https://github.com/cloudfoundry/java-buildpack/commit/b08a69221a9ecfa61a9bfd568639f891b9313a19 наши приложения также не удалось загрузить/вылететь с ошибкой OutOfMemory:Metaspace . Похоже, что калькулятор памяти (v3+) больше не использует ~10% памяти для метапространства, а устанавливает максимальный размер метапространства на ~56 м.

Обходной путь: используйте выпуск v3.14 (https://github.com/cloudfoundry/java-buildpack.git#v3.14) вместо последнего.

Мы наблюдаем похожие проблемы, но вызванные недостаточным количеством CompressedClassSpace — это не так уж и далеко, что дает нам 8385K , тогда как на самом деле нам нужно больше, например 8704K .

@markbigler Калькулятор памяти v3 оценивает потребление метапространства на основе количества файлов классов в приложении. Когда этого недостаточно, вы можете установить предел метапространства, используя, например:

cf set-env app-name JAVA_OPTS '-XX:MaxMetaspaceSize=100m'

@ipsi Аналогично для сжатого пространства класса. Вы можете установить его, используя, например:

cf set-env app-name JAVA_OPTS '-XX:CompressedClassSpaceSize=20m'

такая же проблема здесь, выходит ошибка outofmemory

Та же проблема здесь. Использование старой версии пакета сборки временно решило эту проблему:

cf push -b https://github.com/cloudfoundry/java-buildpack.git\#v3.12

Вопрос StackOverflow к этой теме: http://stackoverflow.com/questions/42576613/java-spring-application-cannot-start-up-on-cloudfoundry-outofmemoryerror-compre

спасибо, что сработало!

Здесь мы видим аналогичные проблемы, вычисление класса не удастся для клиентов, использующих наш агент, поскольку наш javaagent является собственным двоичным файлом из соображений производительности. Я бы хотел, чтобы калькулятор был немного менее агрессивным или чтобы были инструкции по управлению функциями калькулятора через расширение. Необходимость сообщать всем нашим клиентам о необходимости вручную определять дополнительные параметры Java неоптимальна...

@akirasoft Спасибо за описание вашего варианта использования. Как бы вы хотели повлиять на поведение калькулятора? Например, имеет ли смысл скорректировать оценку количества загруженных классов (которую сборочный пакет Java передает калькулятору памяти), а затем позволить калькулятору получить параметры памяти на основе новой оценки? Если да, добавляет ли ваш javaagent фиксированное количество классов или добавленное число зависит (линейно?) от количества классов, загружаемых приложением?

@glyn наш след будет дополнительным плоским пространством для размещения нашего агента, а затем немного больше места пропорционально в зависимости от классов, чем ожидает ваш калькулятор, скажем, на 1-3% больше, если я угадал. Вообще говоря, мне кажется, что калькулятор слишком агрессивен, судя по другим комментариям здесь. Все отлично работало в прошлом году или около того с предыдущим калькулятором.

То же самое. Это приложение (https://github.com/EuregJUG-Maas-Rhine/site, Spring Boot) больше не запускается (CompressedClassSpace).

У меня такая же проблема. Откат на более старую версию тоже помог мне.

Такая же проблема и с моими приложениями. Откат к версии 3.13

Мы также видим OutOfMemoryErrors:

2017-03-06T09:20:39.44+0900 [App/0] OUT # java.lang.OutOfMemoryError: Compressed class space

возможно эвристика v3 нуждается в настройке

@akirasoft «некоторое дополнительное плоское пространство», вероятно, будет разделено на кучу, метапространство и сжатое пространство классов (или permgen в Java 7) и, возможно, даже может повлиять на зарезервированный кеш кода и прямое потребление памяти, поэтому недостаточно добавить константу в единая формула для учета потребностей агента. Можно ли сформулировать потребление агентом «плоского пространства» с точки зрения эквивалентного количества загруженных классов? Подробнее о том, как происходил расчет, см. В дизайне калькулятора памяти v3.

Мы находимся в процессе того, чтобы калькулятор памяти выделял больше метапространства и сжатого пространства класса. Подробнее см. коммит c9867a6 .

Доступен калькулятор памяти v3.2.0.RELEASE. Пожалуйста, повторите отправку приложений и посмотрите, работают ли они теперь.

@glyn мы говорили через Slack, но теперь все выглядит намного лучше, спасибо за исправление!

Я вернулся к buildpack v3.12, он работает хорошо.

Поскольку речь шла о более точном выпуске №391, я пока закрываю этот вопрос.

Спасибо всем за помощь.