Java-buildpack: Die Java-App kann nicht mit der Buildpack-Version b08a692 gestartet werden

Bestätigt. Wir sehen dieses Problem auch,

Könnten Sie bitte den genauen Fehler aus den Anwendungsprotokollen posten?

Der Java-Buildpack-Speicherrechner wurde durch Commit b08a692 auf v3 aktualisiert. v3 respektiert die OpenJDK-Standardwerte für den reservierten Code-Cache, der bei Java 8 240 MB beträgt. Es ist wahrscheinlich, dass dies der Grund dafür ist, dass die Anwendung nicht gestartet werden kann. Sie können den vom Speicherrechner verwendeten Wert wie im folgenden Beispiel überschreiben:

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

Sie müssen jedoch eine geeignete Größe auswählen, denn wenn Sie sie zu klein machen, könnte der CPU-Verbrauch der Anwendung hoch werden.

Aufgrund von Commit https://github.com/cloudfoundry/java-buildpack/commit/b08a69221a9ecfa61a9bfd568639f891b9313a19 konnten unsere Anwendungen auch nicht geladen werden/stürzten mit OutOfMemory:Metaspace ab. Es scheint, dass der Speicherrechner (v3+) nicht mehr ~10% Speicher für den Metaspace verwendet, sondern die maximale Metaspace-Größe auf ~56m setzt.

Problemumgehung: Verwenden Sie Version v3.14 (https://github.com/cloudfoundry/java-buildpack.git#v3.14) anstelle der neuesten Version.

Wir sehen ähnliche Probleme, aber verursacht durch unzureichende CompressedClassSpace - es ist nicht zu weit weg und gibt uns 8385K , während wir eigentlich mehr wie 8704K brauchen.

@markbigler Der v3-Speicherrechner schätzt den Metaspace-Verbrauch basierend auf der Anzahl der Klassendateien in der Anwendung. Wenn dies nicht ausreicht, können Sie das Metaspace-Limit beispielsweise folgendermaßen festlegen:

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

@ipsi Ähnlich für komprimierten Klassenraum. Sie können es zum Beispiel folgendermaßen einstellen:

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

gleiches Problem hier, immer outofmemory Fehler

Dasselbe Problem hier. Die Verwendung der alten Version des Buildpacks löste es vorübergehend:

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

StackOverflow-Frage zu diesem Thema: http://stackoverflow.com/questions/42576613/java-spring-application-cannot-start-up-on-cloudfoundry-outofmemoryerror-compre

danke das hat funktioniert!

Wir sehen hier ähnliche Probleme, die Klassenberechnung schlägt für Kunden fehl, die unseren Agenten verwenden, da unser Javaagent aus Leistungsgründen eine native Binärdatei ist. Ich würde mir wünschen, dass der Taschenrechner etwas weniger aggressiv ist, oder einige Anweisungen zum Manipulieren der Funktionalität des Taschenrechners über eine Erweiterung. Allen unseren Kunden sagen zu müssen, dass sie zusätzliche Java-Optionen manuell definieren müssen, ist suboptimal...

@akirasoft Vielen Dank für die Beschreibung Ihres Anwendungsfalls. Wie möchten Sie das Verhalten des Rechners beeinflussen? Wäre es beispielsweise sinnvoll, die Schätzung der Anzahl der geladenen Klassen (die das Java-Buildpack an den Speicherrechner übergibt) anzupassen und dann den Rechner die Speichereinstellungen basierend auf der neuen Schätzung ableiten zu lassen? Wenn ja, fügt Ihr Javaagent eine feste Anzahl von Klassen hinzu oder hängt die hinzugefügte Anzahl (linear?) von der Anzahl der von der Anwendung geladenen Klassen ab?

@glyn unsere Grundfläche wird etwas zusätzlicher flacher Platz sein, um unseren Agenten zu halten, und dann ein bisschen mehr Platz, basierend auf den Klassen, als Ihr Taschenrechner erwartet, sagen wir 1-3 % zusätzlich, wenn ich schätze. Im Allgemeinen sieht es für mich so aus, als wäre der Rechner basierend auf anderen Kommentaren hier etwas zu aggressiv. Mit dem vorherigen Rechner hat im letzten Jahr alles super funktioniert.

Hier gilt das gleiche. Diese Anwendung (https://github.com/EuregJUG-Maas-Rhine/site, Spring Boot) startet nicht mehr (CompressedClassSpace).

Ich habe auch das gleiche Problem. Ein Zurücksetzen auf eine ältere Version hat es auch für mich behoben.

Auch bei meinen Apps das gleiche Problem. Rollback auf v3.13

Wir sehen auch OutOfMemoryErrors:

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

Vielleicht müssen die v3-Heuristiken optimiert werden

@akirasoft "etwas zusätzlicher flacher Speicherplatz" wird wahrscheinlich auf Heap, Metaspace und komprimierten Klassenraum (oder Permgen in Java 7) aufgeteilt und kann sich möglicherweise sogar auf den reservierten Code-Cache und den direkten Speicherverbrauch auswirken, sodass es nicht ausreicht, eine Konstante hinzuzufügen eine einzige Formel, um die Bedürfnisse eines Agenten zu berücksichtigen. Ist es möglich, den „Flat Space“-Verbrauch des Agenten in Bezug auf eine äquivalente Anzahl geladener Klassen zu formulieren? Siehe das Design des Speicherrechners v3 für Details darüber, wie die Berechnung zustande kam.

Wir sind dabei, den Speicherrechner dazu zu bringen, mehr Metaspace und komprimierten Klassenraum zuzuweisen. Siehe Commit c9867a6 für Details.

Speicherrechner v3.2.0.RELEASE ist verfügbar. Bitte wiederholen Sie Ihre Anwendungs-Pushs und sehen Sie, ob sie jetzt funktionieren.

@glyn wir haben über Slack gesprochen, aber jetzt sieht alles viel besser aus, danke für die Lösung!

Ich bin auf Buildpack v3.12 zurückgekehrt, es funktioniert gut.

Da auf die genauere Ausgabe Nr. 391 verwiesen wurde, schließe ich diese Ausgabe vorerst.

Danke für die Hilfe aller.