← Middleware: compreender e operar a cadeia
09 / 12 · 50 MIN

Diagnóstico JVM e limites de recursos

Distingue runtime, memória, espera e limites de recolha antes de escolher uma intervenção.

Identificar o runtime e o destino

Java define interfaces comuns, mas o diagnóstico da máquina virtual depende da implementação e da versão. Regista fornecedor, versão, PID, identidade do processo e permissões antes de recolher evidência. Um javacore OpenJ9 e um heap dump HotSpot não são formatos intercambiáveis. Num host com duas aplicações Java, a ordem de listagem não identifica produção; confirma o processo pelo contexto de execução. Escolhe um procedimento suportado e limitado ao destino certo. As referências deste módulo usam HotSpot JDK 25 e documentação OpenJ9, sem afirmar equivalência com qualquer instalação WebSphere.

Memória reservada, comprometida e residente

Um valor de Xmx descreve o máximo de heap configurado, não toda a memória da aplicação. Em NMT, distingue reserved de committed e compara categorias ao longo de uma janela com carga conhecida. O conjunto residente observado pelo sistema operativo tem outro âmbito. Num exemplo, o RSS cresce enquanto categorias NMT variam pouco: investiga memória fora da cobertura e diferenças de contabilização. Não transformes a diferença num diagnóstico automático de leak. Uma baseline permite comparar observações futuras; ativação e custo de tracking devem fazer parte de uma mudança planeada.

Limites do container e sintomas da JVM

O processo precisa de margem para recursos fora do heap, e a recolha de métricas pode não mostrar um pico entre amostras. Se o container termina com OOMKilled, cruza eventos, limite e consumo total; não exijas que exista um OutOfMemoryError Java para aceitar uma terminação externa. Num exercício, aumentar heap de 2 para 3,8 GiB num limite de 4 GiB reduz a margem restante. Noutro, reduzir quota de CPU aumenta throttling e latência com memória estável. Trata cada limite pelo sinal correspondente, antes de ajustar pools ou collectors sem evidência.

Threads, owners e progresso

Uma thread à espera de lock não prova deadlock. No javacore OpenJ9, relaciona o estado e o monitor com o owner e a stack, usando amostras comparáveis para observar progresso. Se o owner muda e o trabalho avança, pode existir contenção grave sem imobilidade permanente. Se o owner permanece numa chamada externa, investiga essa dependência e o tempo de retenção da secção crítica. Num caso com vinte workers bloqueados, adicionar workers não contorna o mesmo monitor. Explica o mecanismo observado e o limite da conclusão antes de escolher mitigação com o responsável.

GC dentro da linha temporal

Garbage collection faz parte da execução normal. Para atribuir lentidão a GC, compara duração e frequência das pausas com os pedidos afetados no mesmo intervalo, considerando o collector e a configuração. Se o tempo de pausa é reduzido e os pedidos esperam sobretudo por I/O, a hipótese dominante pode estar na dependência. Evita escolher um novo collector apenas porque há mensagens de GC durante o incidente. Num exercício, constrói uma linha temporal com pedidos, pausas e esperas, e descreve qual observação apoiaria ou contrariaria cada hipótese. A média de CPU isolada não responde a essa pergunta.

Recolher sem agravar a falha

Escolhe uma recolha que responda à hipótese com um limite de duração, volume e impacto. JFR pode conservar eventos temporais relevantes, mas o perfil escolhido tem custo; heap dumps também podem afetar o serviço e ocupar muito espaço. Para uma falha intermitente de I/O, dados temporais direcionados podem ser mais úteis do que repetir dumps de heap. Confirma destino protegido, espaço, retenção e acesso ao artefacto. Regista a janela e as alterações de instrumentação. O pacote deve permitir análise posterior sem deixar uma recolha permanente ou um filesystem cheio após o incidente.

NA PRÁTICA

Um container de 4 GiB reinicia depois de Xmx subir para 3,8 GiB. O heap não representa toda a memória do processo; correlaciona o limite com consumo e eventos antes de aumentar novamente.

Armadilhas comuns

HotSpot e OpenJ9 como ferramentas idênticas; reserved como RAM ocupada; espera como deadlock; dumps sem limite.

Tópicos relacionados: Investigar JVM, heap e pausas · Relacionar threads, pools e dependências · Operar TLS, certificados e configuração

Leva esta ideia contigo

Relaciona a pergunta diagnóstica com a ferramenta, o runtime e os limites reais de recursos.

Criar conta

Referência: Native Memory Tracking · DR Middleware 2026.4; HotSpot JDK 25; JDBC 25; PostgreSQL 18; RabbitMQ 4.3; OpenSSL 3.5; explicitly scoped runtime references