Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: Ajustes conforme indicado pelo Jean no chamado FFDN-2621

Índice

Índice
maxLevel4
outlinetrue
exclude.*ndice
stylenone

Plataforma

Produto: TOTVS Fluig Plataforma

Ocorrência


Objetivo

...

O objetivo deste guia é mostrar a configuração correta para evitar

problemas quanto ao consumo de memória pelo

...

servidor de

...

aplicação.

...

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

Este comportamento está correto?

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 HTTP, como de EJB. No arquivo domain.xml em produção , (localizado em [diretório_instalação]/appserver/configuration (release 1.6 ou superiores) ou no arquivo standalone.xml, localizado em [diretório_instalação]/jboss/standalone/configuration (release 1.5.13 e inferiores), 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:1.1">
	<bounded-queue-thread-pool name="http-pool">
		5.0">
<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="10050" />
			<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 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.

Consulte mais informações a respeito neste link.

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