L'application Java/Spring ne peut pas démarrer sur cloudfoundry: OutOfMemoryError Espace compressé

Question

Après le déploiement d'une nouvelle version de notre logiciel Java/Spring Boot sur Swisscom Developer Cloud, exécuté sur CloudFoundry, le démarrage a échoué avec l'erreur suivante: OutOfMemoryError: Compressed class space. Nous avons donc décidé de déployer une version précédente du logiciel, la version qui était en cours d'exécution juste avant: La même erreur s'est produite. Nous ne sommes pas passés de Java7 à Java8 et nous n'avons pas non plus modifié de configuration. Cela conduit à la question: est-ce vraiment une erreur de notre côté ou plutôt du côté du serveur?

---

Nous avons ensuite essayé d'augmenter le MaxMetaspaceSize en réglant la variable JBP_CONFIG_OPEN_JDK_JRE l'une des lignes suivantes:

[jre: {version: 1.8.0_+}, memory_calculator: {memory_sizes: {metaspace: 128m}}] 
{memory_calculator: {memory_sizes: {metaspace: 128m}}} 
{memory_sizes: {metaspace: 128m}} 

L'application toujours mis en garde, que la valeur de memory_sizes était invalide. Quel est le format correct de cette variable YAML?

[ConfigurationUtils] WARN User config value for 'memory_sizes' is not valid, existing property not present 

---

Nous avons supprimé alors l'application Java et le service de base de données sur la console développeur Swisscom et recréée. Cela n'a eu aucun effet, la même erreur s'est produite.

Enfin, savez-vous pourquoi cette erreur se produit soudainement, même avec une version qui fonctionnait correctement il y a quelques minutes?

---

EDIT:

Ceci est le manifeste ([database-service-name] et [application-name] ont été remplacés):

--- 
path: . 
instances: 1 
buildpack: https://github.com/cloudfoundry/java-buildpack 
services: 
- [database-service-name] 
applications: 
- name: [application-name] 
    domain: scapp.io 
    host: [application-name] 
    memory: 1024M 
    disk_quota: 1024M 
    env: 
    SPRING_PROFILES_ACTIVE: stage, cloudfoundry 

version de Java est (selon les journaux):

2017-03-03 11:47:02 [STG/0] OUT -----> Java Buildpack Version: b08a692 | https://github.com/cloudfoundry/java-buildpack#b08a692 

Cette commande semble être exécutée (dans les journaux après l'accident):

2017-03-03 11:46:25 [APP/PROC/WEB/0] OUT vcap 8 0 99 10:46 ? 00:01:09 /home/vcap/app/.java-buildpack/open_jdk_jre/bin/java -Djava.io.tmpdir=/home/vcap/tmp -XX:OnOutOfMemoryError=/home/vcap/app/.java-buildpack/open_jdk_jre/bin/killjava.sh -XX:MaxDirectMemorySize=10M -XX:MaxMetaspaceSize=68540K -XX:ReservedCodeCacheSize=240M -XX:CompressedClassSpaceSize=8731K -Xmx408104K -Djavax.net.ssl.trustStore=/home/vcap/app/.java-buildpack/container_certificate_trust_store/truststore.jks -Djavax.net.ssl.trustStorePassword=java-buildpack-trust-store-password -cp /home/vcap/app/. org.springframework.boot.loader.WarLauncher 

Answer 1

L'erreur OutOfMemory est survenue parce que le Java buildpack a été modifié pour utiliser la version 3.x de la calculatrice de mémoire. Des problèmes similaires découlant de ce changement sont en discussion dans GitHub issue 390. Veuillez vous référer à ce numéro pour plus de détails.

En général, v3.x du calculateur de mémoire choisit des valeurs pour divers paramètres de mémoire JVM en fonction du nombre de fichiers de classe dans l'application et de certaines valeurs par défaut qui dépendent de la version de Java. Il définit ensuite la taille maximale du tas sur la quantité de mémoire restante.

La version précédente du calculateur de mémoire a été configurée en définissant JBP_CONFIG_OPEN_JDK_JRE. Cependant, v3.x peut être configuré simplement en définissant les paramètres de mémoire Java correspondants dans JAVA_OPTS.Par exemple, vous pouvez définir la taille de metaspace maximale à 100 Mb comme suit:

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

Si vous souhaitez simplement une solution de contournement, vous pouvez utiliser la version de Java buildpack publié avant le changement de calcul de la mémoire:

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

Answer 2

commentaire de développeur Java Swisscom:

For sure they will be reverting the memory heuristics to what they were in 3.13 or at least refine the calculations. The current recommendation to all customers is either

• utiliser ou 3,13
• pour utiliser certaines options explicites avec la variable d'environnement JAVA_OPTS.