Como melhorar a eficiência de aplicativos Java executados no Kubernetes

É otimizado para baixo consumo de memória (Memory footprint) e pequenos tamanhos de heap, está disponível em todas as versões do Java. Seu uso é adequado em ambientes com apenas um core de processamento, ou em aplicações com pequenos conjuntos de dados. Pode-se forçar o uso desse coletor adicionando o argumento: -XX: +UseSerialGC

Podemos dizer que o Paralle/ GC é similar ao Seria/ GC com a diferença de que o Parallel utiliza várias threads para realizar suas operações, assim, em ambientes com vários núcleos de processamento o tempo de pausa em relação ao Serial será menor. Contudo, o Paralle/ GC não funcionará tão bem quanto o

Serial em ambientes que possuírem apenas um núcleo de processamento devido ao overhead causado pela sincronização das threads

O Paralle/ GC é a melhor escolha para uma aplicação na qual o throughput é mais importante que a latência, ele foi definido como default no Java 8 e substituído pelo G1 GC no Java 9. Caso queira habilita-o em outras versões utilize o argumento: -XX: +UseParalleiGC

O objetivo do G1GC é minimizar o tempo de pausa (Latency) do GC e garantir o máximo de rendimento possível (Throughput) sem configuração adicional. Seu modelo fornece uma solução para usuários que executam aplicativos que exigem grandes heaps.

O G1 usa um modelo de previsão de pausa para atender a uma meta de tempo definida pelo usuário (Latency Balance) e seleciona o número de regiões a serem coletadas com base na meta de tempo de pausa especificada. Dessa forma o G1 bem configurado tende a evitar coletas completas (Full GC).

Podemos configurar o tempo máximo de pausa do G1GC com o seguinte argumento XX:MaxGCPauseMillis-200 (200 é o valor default).

O G1GC é a melhor escolha para uma aplicação que necessita de um bom throuchout com uma latência 'controlada, ele foi definido como default a partir do Java 9 e ainda permanece. Para definir o G1 como coletor padrão, basta utilizarmos o seguinte argumento: -XX: +UseG1GC

O Z Garbage Collector, é um coletor de lixo escalável de baixa latência projetado para não ter pausas acima de 10ms.

O ZGC trabalha de forma concorrente, ou seja, sua execução é feita junto com as threads do sistema, isso faz com que a coleta de lixo tenha baixo impacto no response time da aplicação (baixa latência).

Diversas funcionalidades fazem o ZGC ser um incrível coletor, uma delas é a possibilidade de gerenciar dinamicamente suas threads (funcionalidade incluída no Java 17). O ZGC também é capaz de devolver memória não utilizada ao sistema operacional, muito útil em sistemas que o consumo de memória da máquina é algo preocupante, importante salientar que a memória nunca será diminuída abaixo do tamanho mínimo do heap configurado (-Xms<size»)

Um dos pontos a ser observado é o tamanho do Heap alocado. Dependendo da JVM e de quanta memória existe no host, um percentual será estabelecido como valor máximo de Heap.

O ZGC ainda não é um coletor default, ele foi disponibilizado no Java 11 como experimental e liberado para produção a partir do Java 15, ele é a melhor escolha se sua aplicação for focada em baixa latência, para habilitá-lo, basta utilizar o seguinte argumento: -XX: +UsezGC , para versões entre o Java 11 e 15 é necessário adicionar o seguinte argumento: -XX+UnlockExperimentalVMOptions

Sempre que uma aplicação Java é iniciada, um processo chamado Ergonomics da JVM coleta dados do host e define qual o Garbage Collector, tamanho do heap e tipo de compilador deve ser usado pela aplicação. Esse processo já existe muito antes do advento de containers, portanto, temos que tomar um certo cuidado e verificar se o Ergonomics foi assertivo em suas definições quando executamos aplicações em containers.

Quando uma aplicação Java é executada num host que possui 2 ou mais processadores e mais de 1792mb de memória a JVM vai optar por definir um Garbage Collector que seja MultiThread, caso contrario ela utilizará o coletor Serial que é SingleThread.

Como mencionado anteriormente, quando executamos nossas aplicações num cluster Kubernetes que possui Nodes super modernos e potentes, devemos usufruir desses recursos que são disponibilizados. Consequentemente a isso, muitas das vezes se faz necessária a definição manual de qual coletor de lixo nossa aplicação deve utilizar.

Para auxiliar na escolha do coletor, vamos tomar como base algumas condições: versão da JVM, tamanho do heap, ambiente Single ou multi thread, dentre outras.

Importante deixar claro que a tabela apresentada não deve ser levada como verdade absoluta. O ideal é que sejam efetuados testes de carga na aplicação, simulando o uso real do sistema, colhendo métricas para que seja mais assertivo a escolha do coletor de lixo.

A memória NonHeap é uma área de armazenamento importante para várias estruturas de dados usadas pelo JVM. A memória NonHeap é usada para armazenar informações que são necessárias para a execução do programa. Podemos dividi-la nas seguintes subcategorias:

A memória NonHeap tem menor probabilidade de variar sob carga. Depois que uma aplicação tiver carregado todas as classes que usará e o compilador JIT estiver totalmente aquecido, as coisas se estabeleceram em um estado estável.

A memória heap é o espaço onde os objetos Java são alocados durante a execução do programa. Se o tamanho da memória heap não for suficientemente grande para alocar todos os objetos necessários, ocorrerá uma exceção de "OutOfMemoryError" e o programa será encerrado abruptamente. Por outro lado, se a memória heap for muito grande, isso pode levar a um consumo excessivo de recursos do sistema, o que pode afetar negativamente o desempenho do programa e do sistema como um todo.

Como mencionado anteriormente, o processo Ergonomics da JVM é responsável por definir o tamanho da Heap. Para isso, ele leva em consideração a quantidade de memória que foi disponibilizada para o container.

A tabela a seguir mostra o tamanho de heap máximo padrão, dependendo da quantidade de memória disponível:

O Ergonomics sabe que existem outros fatores que afetam a disponibilidade de memória, como outros processos em execução, fragmentação da memória, tamanho da paginação, entre outros.

É importante encontrar um equilíbrio entre o tamanho da memória heap e o consumo de recursos do sistema. Isso pode ser feito ajustando a configuração do tamanho da memória heap através das opções de linha de comando da JVM, como "-Xmx" (que define o tamanho máximo da memória heap) e "-XX:MaxRAMPercentage" (que limita a quantidade máxima de memória que o processo da JVM pode alocar com base em uma porcentagem da memória disponível no container). O ajuste adequado dessas opções pode ajudar a evitar problemas de "OutOfMemoryError", garantir um desempenho ideal do programa, bem como, diminuição de custos quando for mal dimensionada.

Alguns estudos indicam que Microsserviço Java, quando executados em containers podem utilizar como valor máximo de heap até 75% do valor total de memória. Para realizar essa configuração, basta adicionar o seguinte argumento na inicialização da JVM: