Java-buildpack: ビルドパックバージョンb08a692でJavaアプリを起動できません
-----> Java Buildpack Version: b08a692 | https://github.com/cloudfoundry/java-buildpack.git#b08a692
-----> Downloading Open Jdk JRE 1.8.0_121 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_121.tar.gz (found in cache)
Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (0.9s)
-----> Downloading Open JDK Like Memory Calculator 3.1.0_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-3.1.0_RELEASE.tar.gz (0.0s)
Loaded Classes: 14911, Threads: 300, JAVA_OPTS: ''
-----> Downloading Container Certificate Trust Store 2.0.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-2.0.0_RELEASE.jar (found in cache)
Adding certificates to .java-buildpack/container_certificate_trust_store/truststore.jks (0.3s)
-----> Downloading Tomcat Instance 8.5.11 from https://java-buildpack.cloudfoundry.org/tomcat/tomcat-8.5.11.tar.gz (found in cache)
Expanding Tomcat Instance to .java-buildpack/tomcat (0.1s)
-----> Downloading Tomcat Lifecycle Support 2.5.0_RELEASE from https://java-buildpack.cloudfoundry.org/tomcat-lifecycle-support/tomcat-lifecycle-support-2.5.0_RELEASE.jar (found in cache)
-----> Downloading Tomcat Logging Support 2.5.0_RELEASE from https://java-buildpack.cloudfoundry.org/tomcat-logging-support/tomcat-logging-support-2.5.0_RELEASE.jar (found in cache)
-----> Downloading Tomcat Access Logging Support 2.5.0_RELEASE from https://java-buildpack.cloudfoundry.org/tomcat-access-logging-support/tomcat-access-logging-support-2.5.0_RELEASE.jar (found in cache)
-----> Downloading Tomcat External Configuration 8.5.11 from https://geapmcfg.run.aws-jp01-pr.ice.predix.io/tomcatcfg.tar.gz (found in cache)
Expanding Tomcat External Configuration to .java-buildpack/tomcat (0.0s)
-----> Uploading droplet (145M)
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 failing
FAILED
Error restarting application: Start unsuccessful
pxie
全てのコメント20件
確認済み。 この問題も発生していますが、
grover-ws-2
2017年03月03日
アプリケーションログから正確な障害を投稿してください。
Javaビルドパックメモリ計算機は、コミットb08a692によってv3にアップグレードされました。 v3は、予約済みコードキャッシュのOpenJDKのデフォルトを尊重します。これは、Java8では240メガバイトです。 これがアプリケーションの起動に失敗する原因である可能性があります。 次の例のように、メモリ計算機で使用される値を上書きできます。
cf set-env app-name JAVA_OPTS '-XX:ReservedCodeCacheSize=64m'
ただし、サイズを小さくしすぎると、アプリケーションのCPU消費量が高くなる可能性があるため、適切なサイズを選択する必要があります。
glyn
2017年03月03日
https://github.com/cloudfoundry/java-buildpack/commit/b08a69221a9ecfa61a9bfd568639f891b9313a19をコミットしたため、アプリケーションもOutOfMemory:Metaspaceでロード/クラッシュできませんでした。 メモリ計算機（v3 +）は、メタスペースに最大10％のメモリを使用しなくなりましたが、最大メタスペースサイズを約56mに設定しているようです。
回避策：最新ではなく、リリースv3.14（https://github.com/cloudfoundry/java-buildpack.git#v3.14）を使用します。
markbigler
2017年03月03日
同様の問題が発生していますが、 CompressedClassSpaceが不十分であることが原因です。それほど遠くないので、 8385Kが得られますが、実際には8704Kのようなものが必要です。
ipsi
2017年03月03日
@markbigler v3メモリ計算機は、アプリケーション内のクラスファイルの数に基づいてメタスペースの消費量を推定します。 これが不十分な場合は、次を使用してメタスペース制限を設定できます。
cf set-env app-name JAVA_OPTS '-XX:MaxMetaspaceSize=100m'
@ipsi圧縮されたクラススペースについても同様です。 たとえば、次を使用して設定できます。
cf set-env app-name JAVA_OPTS '-XX:CompressedClassSpaceSize=20m'
ここでも同じ問題が発生し、メモリ不足エラーが発生します
kkorada
2017年03月03日
ここで同じ問題。 古いバージョンのビルドパックを使用すると、一時的に解決されました。
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
ssc-hrep3
2017年03月03日
うまくいったありがとう！
kkorada
2017年03月03日
ここでも同様の問題が発生しています。パフォーマンス上の理由から、javaagentはネイティブバイナリであるため、エージェントを使用しているお客様のクラス計算は失敗します。 電卓を少し攻撃的にしないか、拡張機能を介して電卓の機能を操作するためのいくつかの指示を表示したいと思います。 すべてのお客様に追加のJavaオプションを手動で定義するように指示する必要があるのは、最適ではありません...
akirasoft
2017年03月03日
@akirasoftユースケースを説明していただきありがとうございます。 電卓の動作にどのように影響しますか？ たとえば、ロードされたクラスの数の見積もり（Javaビルドパックがメモリ計算機に渡す）を調整してから、計算機が新しい見積もりに基づいてメモリ設定を取得できるようにすることは理にかなっていますか？ その場合、javaagentは固定数のクラスを追加しますか、それとも追加される数はアプリケーションによってロードされるクラスの数に（線形に）依存しますか？
glyn
2017年03月03日
@glynフットプリントは、エージェントを保持するための追加のフラットスペースになり、クラスに基づいて、計算機が予想するよりも少し多くのスペースになります。たとえば、推測すると1〜3％追加されます。 一般的に言って、ここでの他のコメントに基づくと、計算機は少し攻撃的すぎるように見えます。 以前の計算機では、過去1年ほどすべてがうまく機能していました。
akirasoft
2017年03月03日
こっちも一緒。 このアプリケーション（https://github.com/EuregJUG-Maas-Rhine/site、Spring Boot）は起動しなくなりました（CompressedClassSpace）。
michael-simons
2017年03月03日
私も同じ問題を抱えています。 古いバージョンにロールバックすると、私も修正されました。
wpegg-dev
2017年03月04日
私のアプリでも同じ問題があります。 v3.13へのロールバック
krishna383
2017年03月05日
OutOfMemoryErrorsも見られます：
2017-03-06T09:20:39.44+0900 [App/0] OUT # java.lang.OutOfMemoryError: Compressed class space
多分v3ヒューリスティックは調整が必要です
CAFxX
2017年03月06日
@akirasoft 「追加のフラットスペース」は、ヒープ、メタスペース、および圧縮クラススペース（またはJava 7ではpermgen）に分割される可能性があり、予約済みコードキャッシュとダイレクトメモリ消費に影響を与える可能性があるため、に定数を追加するだけでは不十分です。エージェントのニーズを考慮した単一の式。 ロードされたクラスの同数の観点から、エージェントの「フラットスペース」の消費をフレーム化することは可能ですか？ 計算方法の詳細については、メモリ計算機v3の設計を参照してください。
glyn
2017年03月06日
現在、メモリ計算機でより多くのメタスペースと圧縮されたクラススペースを割り当てるようにしています。 詳細については、 commitc9867a6を参照してください。
glyn
2017年03月06日
メモリ計算機v3.2.0.RELEASEが利用可能です。 アプリケーションプッシュを再試行して、それらが機能するかどうかを確認してください。
glyn
2017年03月06日
@glynはSlack経由で話しましたが、修正してくれてありがとう、今ではすべてがずっと良く見えます！
akirasoft
2017年03月06日
buildpackv3.12に戻しました。正常に動作します。
より正確な問題＃391が参照されているので、今のところこの問題を閉じます。
みんなの助けに感謝します。
pxie
2017年03月07日
関連する問題
sdeleuze
·
8コメント
chrylis
·
10コメント
CAFxX
·
13コメント
ipsi
·
12コメント
ajay-dbs
·
21コメント
最も参考になるコメント
ここでも同様の問題が発生しています。パフォーマンス上の理由から、javaagentはネイティブバイナリであるため、エージェントを使用しているお客様のクラス計算は失敗します。 電卓を少し攻撃的にしないか、拡張機能を介して電卓の機能を操作するためのいくつかの指示を表示したいと思います。 すべてのお客様に追加のJavaオプションを手動で定義するように指示する必要があるのは、最適ではありません...