Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Índice

Índice
 

...

maxLevel
 
4

Plataforma

Produto:  fluig

Versão: Se aplica a todas as versões

Ocorrência

outlinetrue
exclude.*ndice
stylenone


Objetivo

O objetivo deste guia é mostrar a configuração correta para evitar Estamos tendo problemas quanto ao consumo de memória pelo Jboss servidor de produçãoaplicação.

Configuramos com os seguintes parametros:
-Xms 16g 
-Xmx 16g 
-XX:MaxPermSize=1024M
Porém o consumo real está em 18GB.

Solução

A memória alocada pela JVM é definida da seguinte forma:

...


Memória alocada pela JVM

O total de memória utilizado pela JVM depende de diversos fatores, como: Java Heap Space, Coletor de lixo, Cache de código, Compilador, Metadados, Threads, etc. Como são muitos os fatores envolvidos, não existe uma maneira garantida de estimar o total de memória que será utilizada por um processo Java.

Bloco de código
Total memory = Heap + Code Cache + Metaspace + Symbol tables + Other JVM structures + Thread stacks + Direct buffers + Mapped files + Native Libraries + Malloc overhead + ...

O parâmetro XMX define o quanto de memória estará disponível para o Java Heap Space (memória dinâmica) que é uma das áreas de memória utilizada pela JVM (Java Virtual Machine).

Devido a um uso mais alto temos um consumo mais elevado das threads tanto de httpHTTP, como de EJB. No standalone em produção, podearquivo domain.xml em produção (localizado em [diretório_instalação]/appserver/configuration) pode-se verificar que a configuração de threads está desta forma:

Bloco de código
languagexml
themeEclipse
<?xml version="1.0" encoding="UTF-8"?>
<subsystem xmlns="urn:jboss:domain:threadsjca:15.10">
<bounded-queue-thread-pool name="http-pool">
<core-threads count="100"/>
<archive-validation enabled="true" fail-on-error="true" fail-on-warn="false" />
<bean-validation enabled="true" />
	<default-workmanager>
		<short-running-threads>
			<core-threads count="50" />
			<queue-length count="50" />
			<max-threads count="50" />
			<keepalive-time time="10" unit="seconds" />
		</short-running-threads>
		<long-running-threads>
			<core-threads count="50" />
			<queue-length count="2050" />
			<max-threads count="30050" />
			<keepalive-time time="1510" unit="seconds" />
		</bounded-queue-thread-pool>long-running-threads>
	</default-workmanager>
	<cached-connection-manager />
</subsystem>

A configuração e o comportamento estão corretos, quanto Quanto maior o uso, mais alto será o consumo de memória, os . Os espaços de memória são configurados separadamente, o valor máximo é definido pela soma das variáveis (como explicado acima) e o uso real vai variar conforme a carga de processamento atual.

Mais informações em: https://plumbr.eu/blog/memory-leaks/why-does-my-java-process-consume-more-memory-than-xmx

Portanto esse comportamento é normal, principalmente em ambientes mais robustos onde este comportamento do gerenciamento de memória da JVM é mais visível, devido ao maior volume de requisições.