Java-buildpack: No se puede iniciar la aplicación Java con la versión buildpack b08a692

Confirmado. También estamos viendo este problema,

Por favor, ¿podría publicar la falla precisa de los registros de la aplicación?

La calculadora de memoria Java buildpack se actualizó a v3 mediante la confirmación b08a692. v3 respeta los valores predeterminados de OpenJDK para el caché de código reservado, que en Java 8 es de 240 megas. Parece probable que esto sea lo que está causando que la aplicación no se inicie. Puede anular el valor utilizado por la calculadora de memoria como en el siguiente ejemplo:

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

pero deberá elegir un tamaño adecuado porque si lo hace demasiado pequeño, el consumo de CPU de la aplicación podría aumentar.

Debido a la confirmación https://github.com/cloudfoundry/java-buildpack/commit/b08a69221a9ecfa61a9bfd568639f891b9313a19 , nuestras aplicaciones tampoco pudieron cargarse/se bloquearon con OutOfMemory:Metaspace . Parece que la calculadora de memoria (v3+) ya no usa ~10 % de memoria para el metaespacio, sino que establece el tamaño máximo del metaespacio en ~56 m.

Solución alternativa: use la versión v3.14 (https://github.com/cloudfoundry/java-buildpack.git#v3.14) en lugar de la última.

Estamos viendo problemas similares, pero causados ​​por CompressedClassSpace insuficientes; no está demasiado lejos, dándonos 8385K , mientras que en realidad necesitamos más como 8704K .

@markbigler La calculadora de memoria v3 estima el consumo de metaespacio en función de la cantidad de archivos de clase en la aplicación. Cuando esto es insuficiente, puede establecer el límite de metaespacio usando, por ejemplo:

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

@ipsi De manera similar para el espacio de clase comprimido. Puede configurarlo usando, por ejemplo:

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

mismo problema aquí, obteniendo un error de memoria insuficiente

Mismo problema aquí. El uso de la versión anterior del paquete de compilación lo resolvió temporalmente:

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

Pregunta de StackOverflow sobre este tema: http://stackoverflow.com/questions/42576613/java-spring-application-cannot-start-up-on-cloudfoundry-outofmemoryerror-compre

gracias eso funciono!

Estamos viendo problemas similares aquí, el cálculo de la clase fallará para los clientes que usan nuestro agente, ya que nuestro javaagent es un binario nativo por motivos de rendimiento. Me gustaría ver que la calculadora sea un poco menos agresiva o algunas instrucciones sobre cómo manipular la funcionalidad de la calculadora a través de una extensión. Tener que decirles a todos nuestros clientes que definan manualmente las opciones adicionales de Java es subóptimo...

@akirasoft Gracias por describir su caso de uso. ¿Cómo le gustaría influir en el comportamiento de la calculadora? Por ejemplo, ¿tendría sentido ajustar la estimación de la cantidad de clases cargadas (que el paquete de compilación de Java pasa a la calculadora de memoria) y luego dejar que la calculadora obtenga la configuración de la memoria en función de la nueva estimación? Si es así, ¿su javaagent agrega un número fijo de clases o el número agregado depende (¿linealmente?) del número de clases cargadas por la aplicación?

@glyn nuestra huella será un espacio plano adicional para albergar a nuestro agente y luego un poco más de espacio proporcionalmente en función de las clases de lo que espera su calculadora, digamos 1-3% adicional, si tuviera que adivinar. En términos generales, me parece que la calculadora es demasiado agresiva según otros comentarios aquí. Todo funcionó muy bien durante el último año con la calculadora anterior.

Aquí igual. Esta aplicación (https://github.com/EuregJUG-Maas-Rhine/site, Spring Boot) ya no se inicia (CompressedClassSpace).

También tengo el mismo problema. Volver a una versión anterior también me lo arregló.

El mismo problema con mis aplicaciones también. Volviendo a v3.13

También estamos viendo OutOfMemoryErrors:

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

tal vez la heurística v3 necesita ajuste

@akirasoft "algún espacio plano adicional" probablemente se dividirá en almacenamiento dinámico, metaespacio y espacio de clase comprimido (o permgen en Java 7) y es posible que incluso afecte el caché de código reservado y el consumo directo de memoria, por lo que no es suficiente agregar una constante a una única fórmula para tener en cuenta las necesidades de un agente. ¿Es posible enmarcar el consumo de "espacio plano" del agente en términos de un número equivalente de clases cargadas? Consulte el diseño de la calculadora de memoria v3 para obtener detalles sobre cómo se realizó el cálculo.

Estamos en el proceso de hacer que la calculadora de memoria asigne más metaespacio y espacio de clase comprimido. Ver compromiso c9867a6 para más detalles.

La calculadora de memoria v3.2.0.RELEASE está disponible. Vuelva a intentar las inserciones de su aplicación y vea si ahora funcionan.

@glyn hablamos a través de Slack, pero todo se ve mucho mejor ahora, ¡gracias por la solución!

He vuelto al buildpack v3.12, funciona bien.

Dado que se ha referido al número 391 más preciso, cierro este problema por ahora.

Gracias por la ayuda de todos.