Java-buildpack: Não é possível iniciar o aplicativo java com a versão do buildpack b08a692

Confirmado. Também estamos vendo esse problema,

Por favor, você poderia postar a falha precisa dos logs do aplicativo.

A calculadora de memória Java buildpack foi atualizada para v3 pelo commit b08a692. v3 respeita os padrões do OpenJDK para cache de código reservado, que no Java 8 é de 240 megas. Parece provável que seja isso que está causando a falha de inicialização do aplicativo. Você pode substituir o valor usado pela calculadora de memória como no exemplo a seguir:

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

mas você terá que escolher um tamanho adequado, porque se você torná-lo muito pequeno, o consumo de CPU do aplicativo pode se tornar alto.

Devido ao commit https://github.com/cloudfoundry/java-buildpack/commit/b08a69221a9ecfa61a9bfd568639f891b9313a19 , nossos aplicativos também falharam ao carregar/travaram com OutOfMemory:Metaspace . Parece que a calculadora de memória (v3+) não usa mais ~10% de memória para o metaespaço, mas define o tamanho máximo do metaespaço para ~56m.

Solução alternativa: use a versão v3.14 (https://github.com/cloudfoundry/java-buildpack.git#v3.14) em vez da versão mais recente.

Estamos vendo problemas semelhantes, mas causados ​​por CompressedClassSpace insuficiente - não está muito longe, nos dando 8385K , enquanto na verdade precisamos de mais como 8704K .

@markbigler A calculadora de memória v3 estima o consumo de metaespaço com base no número de arquivos de classe no aplicativo. Quando isso for insuficiente, você pode definir o limite do metaespaço usando, por exemplo:

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

@ipsi Da mesma forma para espaço de classe compactado. Você pode configurá-lo usando, por exemplo:

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

mesmo problema aqui, obtendo erro de falta de memória

Mesma questão aqui. Usando a versão antiga do buildpack resolveu temporariamente:

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

Pergunta do StackOverflow para este tópico: http://stackoverflow.com/questions/42576613/java-spring-application-cannot-start-up-on-cloudfoundry-outofmemoryerror-compre

obrigado funcionou!

Estamos vendo problemas semelhantes aqui, o cálculo de classe falhará para clientes que usam nosso agente, pois nosso javaagent é um binário nativo por motivos de desempenho. Eu gostaria de ver a calculadora ser um pouco menos agressiva ou algumas instruções sobre como manipular a funcionalidade da calculadora por meio de uma extensão. Ter que dizer a todos os nossos clientes para definir manualmente opções java adicionais é sub-ótimo...

@akirasoft Obrigado por descrever seu caso de uso. Como você gostaria de influenciar o comportamento da calculadora? Por exemplo, faria sentido ajustar a estimativa do número de classes carregadas (que o buildpack Java passa para a calculadora de memória) e então deixar a calculadora derivar as configurações de memória com base na nova estimativa? Se sim, seu javaagent adiciona um número fixo de classes ou o número adicionado depende (linearmente?) do número de classes carregadas pelo aplicativo?

@glyn nossa pegada será algum espaço plano adicional para manter nosso agente e, em seguida, um pouco mais de espaço proporcionalmente com base nas classes do que sua calculadora está esperando, digamos 1-3% adicional, se eu adivinhar. De um modo geral, parece-me que a calculadora é um pouco agressiva demais com base em outros comentários aqui. Tudo estava funcionando muito bem no último ano com a calculadora anterior.

Mesmo aqui. Este aplicativo (https://github.com/EuregJUG-Maas-Rhine/site, Spring Boot) não inicia mais (CompressedClassSpace).

Eu também tenho o mesmo problema. Reverter para uma versão mais antiga corrigiu isso para mim também.

Mesmo problema com meus aplicativos também. Revertendo para a v3.13

Também estamos vendo OutOfMemoryErrors:

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

talvez a heurística da v3 precise de ajustes

@akirasoft "algum espaço plano adicional" provavelmente será dividido em heap, metaespaço e espaço de classe compactado (ou permgen em Java 7) e pode até afetar o cache de código reservado e o consumo direto de memória, portanto, não é suficiente adicionar uma constante a uma fórmula única para levar em conta as necessidades de um agente. É possível enquadrar o consumo de "espaço plano" do agente em termos de um número equivalente de classes carregadas? Consulte o projeto da calculadora de memória v3 para obter detalhes de como o cálculo ocorreu.

Estamos no processo de fazer a calculadora de memória alocar mais metaespaço e espaço de classe compactado. Veja commit c9867a6 para detalhes.

Calculadora de memória v3.2.0.RELEASE está disponível. Por favor, tente novamente seus pushes de aplicativos e veja se eles funcionam agora.

@glyn falamos via Slack, mas tudo parece muito melhor agora, obrigado pela correção!

Eu voltei para o buildpack v3.12, ele funciona bem.

Como ele foi encaminhado para a edição mais precisa #391, encerro esta edição por enquanto.

Obrigado a ajuda de todos.