cloudfoundry / cloudfoundry/java-buildpack

Support configurable initial/minimum heap size relative to (/as a percentage of) calculated Xmx

オープン
#1,377 コメント 5 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
Go
スター
452
フォーク
2.5k
平均マージ
14時間 57分
マージ済み PR(30日)
23

説明

In the 3.x line of the buildpack, config/open_jdk_jre.yml supported a memory_initials mapping, allowing the initial size of each memory region (heap, permgen, metaspace) to be configured as a percentage of its calculated maximum. (https://github.com/cloudfoundry/java-buildpack/blob/3.x/docs/jre-open_jdk_jre.md). This option no longer appears from v4.0 onward (2017), including the current Go-based v5.x buildpack.

Because -Xmx is only known at container start (it depends on the memory limit assigned to the app instance), we cannot set a matching or proportional -Xms value ourselves via JAVA_OPTS, because we'd need to know the calculated -Xmx ahead of time. In practice this means our JVMs start with a small default initial heap and grow it under load, causing avoidable heap-resize activity that didn't happen back when memory_initials was available.

Could memory_calculator support such an option again to set the initial heap size as a percentage of the calculated max heap? This would let us keep using the automatic memory calculation while avoiding heap growth pauses after startup.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

memory_calculator エントリーポイントから開始し、現在の動作を config/open_jdk_jre.yml にある 3.x の memory_initials マッピングおよび関連ドキュメントと比較します。手動で Xmx を把握しなくても、自動計算された最大ヒープの割合として初期ヒープサイズを設定できるオプションが実現すれば、作業は完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
go, java
領域
build-system, devops
issue の種類
機能追加
難易度
3/5
見積もり時間
1〜2日
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
55/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。