Java-buildpack: デフォルト構成で512M未満のSpringBootアプリケーションを実行できません

メモリ計算機を設定することにより、512M未満で実行することが可能です。
次のマニフェストは私のために働きます（スプリングブート+ 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.+}]'

バニラwebfluxアプリは、実際には60MBのRAMで実行されます。

ほとんどの開発者はヒープサイズのみを気にし、予期しないOOME（Metaspaceなど）を取得する傾向があるため、私はメモリ計算機の大ファンですが、それを改善できることに同意します。
計算機のデフォルトのスレッドサイズ（300？）は、少なくともwebfluxには大きすぎます。

初心者にとって、メモリサイズをカスタマイズする方法を見つけるのはかなり難しいです。
READMEのユースケースによる構成例は非常に役立ちます。

@makingこの問題のタイトルを更新して、デフォルトの構成が（少なくとも）ブートアプリケーションに最適ではないことを明確にしました。 もちろん、256Mとカスタム構成でブートアプリケーションを実行することは完全に可能ですが、デフォルトのメモリ構成は正確とはほど遠いように思えます。多くのユーザーに影響を与えるため、ここで少し進歩させたいと思います。

WebFluxアプリケーションについて言及したスレッドの数は、確かに非常に興味深い点です。ビルドパックは、アプリの種類を検出することで、付加価値を提供できます。 一部のMVCアプリケーションはReactive WebClientを使用できるため、注意が必要な場合がありますが、もっと賢く正確なことができると確信しています。

カスタムメモリ構成は、自動構成メカニズムに問題があることをIMOに強調表示します。 https://github.com/cloudfoundry/java-buildpack-memory-calculator/issues/24で説明されているように、ブートアプリで効果的に使用されるクラスの数（8000〜10000）を明示的に指定すると、生成されるパラメーターは-XX:ReservedCodeCacheSize=240M 、ここで-XX:ReservedCodeCacheSize=32Mを指定します。 この違いは本当に大きいです、私たちはもっと知識のある推測をすることができますか？

また、8000または10000は、ブートアプリによって効果的に使用されるクラスの数です。 ビルドパックがアプリ内のクラスの数と依存関係からそれを計算している場合、メモリ計算機に指定されたクラスの数は人為的に多いと思う傾向があります（現在推測されている値を確認する必要がありますが、ビルドパック） Spring FrameworkJARの性質によるものです。

また、最新のJava8とJava11で利用できる新しいコンテナメモリオプションを活用ますが-XX:InitialRAMPercentage 、 -XX:MaxRAMPercentage 、 -XX:MinRAMPercentageなどのオプションを活用しますか？

@sdeleuzeというトリッキーな問題です。 java-buildpackはjavaのデフォルトを使用しますか？これは、Javaの設定に何らかの考慮が払われ、アプリケーションがデフォルトでCFで実行されていないときと同じように機能できるようにすることを前提としていますか？ または、java-buildpackはデフォルトを変更して初期エクスペリエンスを向上させますが、アプリケーションがCFで期待どおりに実行されない場合、ユーザーは回答を検索し続けますか？

今日、java-buildpackは、今日の典型的なアプリケーションとして、これらの値を信頼するjavaおよびtomcatのデフォルトを使用することを選択しました。 私は個人的に、ユーザーにあまり見えない/明示的ではない方法でアプリケーションに影響を与える可能性のあるJavaのデフォルトを変更するよりも、そのアプローチが好きです。

新しいプロパティに関する限り、 RAMPercentageプロパティについての私の理解は、使用可能なRAMのパーセンテージに基づいてヒープ値を自動的に設定するだけであるということです。 コードキャッシュサイズ、スレッドスタックサイズ、メタスペース、GCメモリオーバーヘッドなどの非ヒープメモリ要件については考慮されていません。その作業は、アプリケーションに必要な非ヒープメモリの量をユーザーが推測するための演習として残されています。 Javaがすべてのメモリプールを適切に管理して、アプリケーションをコンテナのメモリ制約内に維持できる日を楽しみにしています。 しかし、私たちはまだそれから遠く離れていると思います。

ちなみに、これはアプリケーション用に設定したJAVA_OPTSとjreの構成であり、低メモリで安定している必要があり、速度は要因ではありません。

• MaxMetaSizeをプロファイリングで検出されたものに設定しました。
  JAVA_OPTS

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

jre config

  stack_threads: 20