Dimensionar uma JVM dentro de um contêiner: percentual de heap, memória fora do heap e número de CPUs

Objetivo

Um limite de memória do contêiner que a JVM não ultrapasse e um heap grande o bastante para que o coletor não fique rodando o tempo todo, ambos derivados de evidências e não de números copiados.

Pré-requisitos

Um JDK com suporte a contêineres (a referência do comando java o descreve como exclusivo de Linux e habilitado por padrão, podendo ser desligado com -XX:-UseContainerSupport), acesso ao limite de memória e à cota de CPU do cgroup do contêiner e uma forma de executar o serviço sob carga representativa.

Passos

1. Confirme o que a JVM enxerga: inicie com -Xlog:os+container=info (a referência indica trace para o nível máximo de detalhe) e leia o limite de memória e o número de processadores informados. -XX:ActiveProcessorCount=n sobrescreve o número de CPUs quando as cotas induzem a erro; segundo a referência, essa flag é respeitada mesmo sem suporte a contêineres.
2. Escolha um percentual de heap em vez de um tamanho fixo: -XX:MaxRAMPercentage (padrão: 25 por cento da memória disponível para o processo) e -XX:InitialRAMPercentage (padrão: 1,5625 por cento) acompanham o limite, de modo que uma mesma imagem funciona em um contêiner de 1 GB e em um de 4 GB. Um -Xmx fixo ultrapassa silenciosamente um limite menor.
3. Faça o orçamento da memória fora do heap que o percentual precisa deixar livre: metadados de classes (sem limite por padrão; -XX:MaxMetaspaceSize define um teto), uma pilha por thread (-Xss, padrão de 1024 KB em Linux/x64 segundo a referência), buffers de bytes diretos (-XX:MaxDirectMemorySize), o code cache do JIT, estruturas de dados do GC e bibliotecas nativas. O exemplo da própria referência usa -XX:MaxRAMPercentage=75; qualquer percentual escolhido é uma hipótese a ser medida no passo 4, não um valor sabidamente seguro.
4. Meça o processo inteiro: execute sob carga com -XX:NativeMemoryTracking=summary e jcmd <pid> VM.native_memory summary, e compare o total committed com o limite do contêiner e com o contador de memória do próprio cgroup.
5. Defina o limite do contêiner como o pico medido mais uma margem, ou reduza o percentual do heap até que o pico caiba. Nunca faça o orçamento considerando apenas o heap.
6. Reavalie a escolha do coletor: o capítulo de ergonomia seleciona o Serial GC com menos de dois processadores, portanto um contêiner com uma CPU executa um coletor de thread única, a menos que -XX:+UseG1GC seja informado deliberadamente.
7. Registre limite, percentual, número de CPUs e pico medido junto ao manifesto de deployment.

Resultado esperado

O processo permanece abaixo do limite, com tamanho residente estável; os logs do GC mostram um heap que cresce até o teto sem coletas completas constantes; e redimensionar o contêiner altera o heap proporcionalmente, sem precisar de uma nova imagem.

Limites e base de verificação

Percentuais resultam em heaps inesperadamente pequenos em contêineres muito reduzidos; a referência documenta -XX:MinRAMPercentage (padrão de 50 por cento) para heaps de cerca de 125 MB. Consumidores fora do heap, como buffers de rede ou arquivos mapeados em memória, ficam fora da contabilidade da JVM; o contador do cgroup é a autoridade final. Aqui se propõe apenas o procedimento; nenhum tamanho é afirmado para qualquer carga de trabalho.