Java-buildpack: Impossible de démarrer l'application Java avec la version de buildpack b08a692

Confirmé. Nous rencontrons également ce problème,

S'il vous plaît pourriez-vous poster l'échec précis à partir des journaux d'application.

Le calculateur de mémoire Java buildpack a été mis à niveau vers la v3 par le commit b08a692. La v3 respecte les valeurs par défaut d'OpenJDK pour le cache de code réservé, qui sur Java 8 est de 240 Mo. Il semble probable que c'est ce qui empêche le démarrage de l'application. Vous pouvez remplacer la valeur utilisée par le calculateur de mémoire comme dans l'exemple suivant :

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

mais vous devrez choisir une taille appropriée car si vous la faites trop petite, la consommation CPU de l'application pourrait devenir élevée.

En raison de la validation https://github.com/cloudfoundry/java-buildpack/commit/b08a69221a9ecfa61a9bfd568639f891b9313a19 , nos applications n'ont pas pu se charger/se planter avec OutOfMemory:Metaspace . Il semble que le calculateur de mémoire (v3+) n'utilise plus ~10% de mémoire pour le métaspace mais fixe la taille maximale du métaspace à ~56m.

Solution : utilisez la version v3.14 (https://github.com/cloudfoundry/java-buildpack.git#v3.14) au lieu de la dernière.

Nous rencontrons des problèmes similaires, mais causés par un manque de CompressedClassSpace - ce n'est pas trop loin, nous donnant 8385K , alors que nous avons en fait besoin de plus comme 8704K .

@markbigler Le calculateur de mémoire v3 estime la consommation de méta-espace en fonction du nombre de fichiers de classe dans l'application. Lorsque cela est insuffisant, vous pouvez définir la limite du métaspace en utilisant, par exemple :

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

@ipsi De même pour l'espace de classe compressé. Vous pouvez le définir en utilisant, par exemple :

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

même problème ici, erreur de mémoire insuffisante

Même problème ici. L'utilisation de l'ancienne version du buildpack l'a temporairement résolu :

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

Question StackOverflow à ce sujet : http://stackoverflow.com/questions/42576613/java-spring-application-cannot-start-up-on-cloudfoundry-outofmemoryerror-compre

merci ça a marché !

Nous rencontrons des problèmes similaires ici, le calcul de la classe échouera pour les clients utilisant notre agent car notre javaagent est un binaire natif pour des raisons de performances. J'aimerais que la calculatrice soit un peu moins agressive ou quelques instructions sur la manipulation des fonctionnalités de la calculatrice via une extension. Devoir dire à tous nos clients de définir manuellement des options Java supplémentaires n'est pas optimal...

@akirasoft Merci d'avoir décrit votre cas d'utilisation. Comment aimeriez-vous influencer le comportement de la calculatrice ? Par exemple, serait-il judicieux d'ajuster l'estimation du nombre de classes chargées (que le pack de construction Java transmet au calculateur de mémoire), puis de laisser le calculateur dériver les paramètres de mémoire en fonction de la nouvelle estimation ? Si oui, votre javaagent ajoute-t-il un nombre fixe de classes ou le nombre ajouté dépend-il (linéairement ?) du nombre de classes chargées par l'application ?

@glyn, notre empreinte sera un espace plat supplémentaire pour contenir notre agent, puis un peu plus d'espace proportionnellement en fonction des classes que ce que votre calculatrice attend, disons 1 à 3% supplémentaires, si je devais deviner. D'une manière générale, il me semble que la calculatrice est juste un peu trop agressive d'après d'autres commentaires ici. Tout fonctionnait très bien depuis un an environ avec la calculatrice précédente.

Pareil ici. Cette application (https://github.com/EuregJUG-Maas-Rhine/site, Spring Boot) ne démarre plus (CompressedClassSpace).

J'ai aussi le même problème. Revenir à une version plus ancienne l'a également corrigé pour moi.

Même problème avec mes applications. Revenir à la v3.13

Nous voyons également OutOfMemoryErrors :

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

peut-être que l'heuristique v3 a besoin d'être ajustée

@akirasoft "un espace plat supplémentaire" sera probablement divisé entre le tas, le méta-espace et l'espace de classe compressé (ou permgen dans Java 7) et peut même affecter le cache de code réservé et la consommation de mémoire directe, il n'est donc pas suffisant d'ajouter une constante à une formule unique pour tenir compte des besoins d'un agent. Est-il possible de cadrer la consommation "flat space" de l'agent en nombre équivalent de classes chargées ? Voir la conception du calculateur de mémoire v3 pour plus de détails sur la façon dont le calcul a été effectué.

Nous sommes en train de faire en sorte que le calculateur de mémoire alloue plus de méta-espace et d'espace de classe compressé. Voir le commit c9867a6 pour plus de détails.

Le calculateur de mémoire v3.2.0.RELEASE est disponible. Veuillez réessayer vos poussées d'application et voir si elles fonctionnent maintenant.

@glyn nous avons parlé via Slack mais tout semble beaucoup mieux maintenant, merci pour le correctif !

Je suis revenu au buildpack v3.12, cela fonctionne bien.

Puisqu'il a été renvoyé au problème plus précis n ° 391, je ferme ce problème pour le moment.

Merci de l'aide de tous.