Java-buildpack: Невозможно запускать приложения Spring Boot с конфигурацией по умолчанию и <512 МБ

Можно использовать менее 512 МБ, настроив калькулятор памяти.
Для меня работает следующий манифест (весенняя загрузка + webflux).

applications:
- name: myapp
  path: target/myapp-0.0.1-SNAPSHOT.jar
  memory: 256m
  env:
    JAVA_OPTS: '-XX:ReservedCodeCacheSize=32M -XX:MaxDirectMemorySize=32M'
    JBP_CONFIG_OPEN_JDK_JRE: '[memory_calculator: {stack_threads: 30}, jre: {version: 11.+}]'

Приложение vanilla webflux на самом деле работает с оперативной МБ .

Я большой поклонник калькулятора памяти, так как большинство разработчиков, как правило, заботятся только о размере кучи и получают неожиданное OOME (например, Metaspace), но я согласен, что мы могли бы его улучшить.
Размер потока по умолчанию (300?) В калькуляторе будет слишком большим, по крайней мере, для webflux.

Для новичков довольно сложно найти способ настроить размер памяти.
Примеры конфигурации с помощью сценария использования в README были бы очень полезны.

@making Я обновил заголовок этого выпуска, чтобы прояснить, что речь идет о конфигурации по умолчанию, неоптимальной для (по крайней мере) загрузочных приложений. Конечно, вполне возможно запускать загрузочные приложения с 256 МБ и настраиваемой конфигурацией, но конфигурация памяти по умолчанию кажется мне очень далекой от точной, и я бы хотел, чтобы мы добились некоторого прогресса, потому что это влияет на многих пользователей.

Количество потоков, которые вы упомянули для приложения WebFlux, действительно является очень интересным моментом, пакет сборки может обеспечить дополнительную добавленную стоимость, определяя, что это за приложение. Это может быть сложно, поскольку некоторые приложения MVC могут использовать Reactive WebClient , но я уверен, что мы можем сделать что-то более умное и точное.

Ваша настраиваемая конфигурация памяти указывает на то, что в механизме автоматической конфигурации что-то не так. Как объясняется в https://github.com/cloudfoundry/java-buildpack-memory-calculator/issues/24 , если я явно укажу количество классов (от 8000 до 10000), эффективно используемых загрузочными приложениями, сгенерированный параметр будет -XX:ReservedCodeCacheSize=240M , где вы указываете -XX:ReservedCodeCacheSize=32M . Эта разница действительно огромна, можем ли мы сделать более обоснованное предположение?

Также 8000 или 10000 - это количество классов, эффективно используемых загрузочными приложениями. Если пакет сборки вычисляет это из количества классов в приложении + зависимости, я склонен думать, что количество классов, указанных в калькуляторе памяти, будет искусственно большим (мне все равно нужно проверить предполагаемое значение, но пакет сборки) из-за природы Spring Framework JAR.

Мне также интересно, используем ли мы новые параметры памяти контейнера , которые доступны в последних версиях Java 8 и Java 11. Они разработаны для Docker, но я думаю, мы могли бы извлечь из этого пользу и в Cloud Foundry. Знает ли среда выполнения Java, что мы работаем в контейнерах, несмотря на то, что CF не использует Docker? Используем ли мы такие варианты, как -XX:InitialRAMPercentage , -XX:MaxRAMPercentage или -XX:MinRAMPercentage ?

Это сложная проблема @sdeleuze. Использует ли пакет java-buildpack значения по умолчанию java, которые, как мы предполагаем, вошли в настройку java, позволяя приложениям работать по умолчанию, как если бы они не работали в CF? Или java-buildpack меняет настройки по умолчанию, чтобы улучшить первоначальный опыт, но затем оставляет пользователей искать ответы, когда приложение не запускается должным образом, а не в CF?

Сегодня пакет java-buildpack решил использовать значения по умолчанию java и tomcat, полагаясь на эти значения как на типичное сегодня приложение. Мне лично этот подход нравится больше, чем изменение настроек java по умолчанию, которые могут повлиять на приложение способами, не очень видимыми / явными для пользователя.

Что касается новых свойств, то, как я понимаю, свойства RAMPercentage заключаются в том, что они просто автоматически устанавливают значения кучи на основе процента доступной оперативной памяти. Никаких мыслей о требованиях к памяти без кучи, таких как размер кеша кода, размер стека потоков, метапространство, накладные расходы на память GC и т. Д. Эта работа по-прежнему остается для пользователя в качестве упражнения, чтобы угадать, сколько памяти без кучи требуется их приложению. Я с нетерпением жду того дня, когда Java сможет просто правильно управлять всеми пулами памяти, чтобы приложение оставалось в рамках ограничений памяти контейнера. Но я подозреваю, что мы еще очень далеки от этого.

В качестве побочного примечания это конфигурация JAVA_OPTS и jre, которую я установил для своих приложений, которая должна быть стабильной с низким объемом памяти, а скорость не имеет значения.

• Я установил для MaxMetaSize значение, обнаруженное посредством профилирования.
  JAVA_OPTS

-Xss256K -Xms1M -XX:+UseSerialGC -Djava.compiler=none -XX:ReservedCodeCacheSize=2496k -XX:MaxDirectMemorySize=1M

jre конфигурация

  stack_threads: 20