Download - Gerencia de memoria no java
-
Java
Tpicosselecionados
deprogramao
em Gerncia de Memria em Java
Parte II: Monitorao e configurao da mquina
virtual HotSpot
Helder da RochaSetembro 2005
-
Otimizao da JVM HotSpot A HotSpot JVM permite a configurao de vrios
aspectos relacionados gerncia de memria Escolha de JVMs pr-configuradas (servidor e cliente) Ajustes absolutos e relativos do tamanho total e forma de
distribuio do espao do heap Ajuste de tamanho da pilha (para todos os threads) Escolha de diferentes algoritmos e estratgias de coleta de lixo Metas para auto-ajuste (ergonomics) visando performance
(throughput e baixas pausas) Tratamento de referncias fracas (soft references)
Esta apresentao explora esses recursos e aponta estratgias de ajuste visando melhor performance
2
-
Assuntos abordados
Tpicos1. HotSpot JVM: arquitetura de memria2. Parmetros de configurao de memria3. Escolha do coletor de lixo4. Monitorao de aplicaes5. Ajuste automtico (Java 5.0 Ergonomics)6. Apndice: class data sharing
3
-
Opes XX da JVM HotSpot Vrios parmetros de configurao mostrados nesta apresentao
usam opes XX do interpretador Javajava -XX:+Opo1 -XX:Opo2=5 ... [+opes] pacote.Classe
As opes -X e XX no so padronizados No fazem parte da especificao da JVM; podem mudar. Diferem entre algumas implementaes do HotSpot (ex: IBM)
H dois tipos de opes XX Valor booleano -XX: Valor inteiro -XX:=
Nas opes booleanas, o +/- serve para ligar/desligar uma opo-XX:+Opcao (liga uma opo que estava desligada por default)-XX:-Opcao (desliga uma opo que estava ligada por default)
Opes inteiras recebem o valor diretamente-XX:Valor=8
4
-
1. Arquitetura da HotSpot JVM
5
A mquina virtual configurada para as situaes mais comuns da plataforma usada
H duas opes bsicas a escolher Java HotSpot Client VM: minimiza tempo de incio da aplicao
e memria utilizada. Para iniciar a VM com esta opo, use: java client
Java HotSpot Server VM (opcional): maximiza velocidade de execuo da aplicao. Para iniciar a VM com esta opo, use java server
Tamanhos default do heap e geraes permanentes diferem nas duas opes
O tipo de mquina virtual usada pode ser selecionada automaticamente, de acordo com a plataforma Recurso do Java 5.0: JVM ergonomics: mquinas grandes
multiprocessadas usam Server VM e demais usam Client VM
-
Todas as VM HotSpot possuem
Compilador adaptativo Aplicaes so iniciadas usando o interpretador Ao longo do processo o cdigo analisado para localizar
gargalos de performance; trechos ineficientes so compilados e outras otimizaes (ex: inlining) so realizadas
Server VM (opo server) faz otimizaes mais agressivas
Alocao rpida de memria Liberao de memria automtica
Destruio automtica de objetos usando algoritmos eficientes de coleta de lixo adaptados ao ambiente usado
Default coletor serial em client e coletor paralelo de alta eficincia (throughput) em server
Sincronizao de threads escalvel
6
-
Coleta de lixo em Java: breve histria At a verso 1.1: nico coletor mark-and-sweep
Causa fragmentao de memria Alto custo de alocao e liberao (o heap inteiro precisava ser
varrido em cada coleta): pausas longas, throughput baixo
HotSpot (Java 1.2 e posterior): generational collector Gerao jovem: algortmo de cpia (garante que o espao livre
no heap seja sempre contguo: alocao eficiente) Gerao antiga: algoritmo Mark-Compact (sem fragmentao)
Java 1.3 a 1.5: vrias implementaes Diversas diferentes implementaes de algoritmos baseados em
geraes (serial, throughput, paralelo, concorrente, incremental) 1.5: auto-ajuste, escolha e otimizao baseado em ergonmica
Java 1.6 (Mustang) e Java 1.7 (Dolphin): ?7
-
Coletor de lixo serial Default na HotSpot Client VM Heap dividido em geraes (generational GC)
Heap total contm gerao jovem (trs reas) e gerao estvel(geralmente maior)
Gerao permanente (sem coleta ou coletada raramente) alocada parte do heap total
Algoritmos de coleta de lixo usados Gerao jovem: algoritmo de cpia com duas origens e dois
destinos (um temporrio e um permanente): coletas pequenas e freqentes: minor collection
Gero estvel (velha): algoritmo mark-compact: coletas maiores (totais) e raras: major collection
Gerao permanente: mark-sweep-compact: coleta muito rara
8
-
HotSpot: arquitetura do heap
virtual
virtual
virtual
Heap totalmximo-Xmx
Heapmnimo-Xms
Gerao jovem (young generation)
Gerao estvel (velha) (tenured generation)
Gerao permanente (permanent generation)
+
-XX:PermSize*
Coletas menores (freqentes)
Coletas maiores (infreqentes)
Coletas raras ou ausentes-XX:MaxPermSize
9* opes X e XX: da JVM (da Sun) no so padronizadas e podem mudar no futuro
-
Gerao jovem Usa algoritmo de cpia (coleta menor)
Objetos so criados no den (sempre origem) Sobreviventes so copiados para reas menores
10
virtual
den
Sobreviventes trocam de funo a
cada coleta
Sobreviventes(survivors)
Um dos sobreviventes (destino) est sempre vazio a qualquer momento
Origem (From)
Destino (To)
-
Coleta menor
Minor collection (Partial GC) Freqentes e rpidas
Acontecem sempre que o Eden enche Usam algoritmo de cpia (copying algorithm)
com duas reas de origem (from_space) e duas reas de destino (to_space) reas sobreviventes alternam funo de origem e
destino (uma sempre est vazia) rea Eden sempre origem; Gerao estvel sempre destino
11
-
Coletas menores: algoritmo Quando o GC executa uma coleta menor
Copia todos os objetos alcanveis do den e sobrevivente origem para a rea sobrevivente destino e/ou gerao estvel
Se objeto no couber no sobrevivente, vai para gerao estvel O GC pode promover um objeto que j foi copiado vrias vezes
entre as regies sobreviventes e torn-lo estvel
No final da coleta, den e rea sobrevivente origemesto vazios Origem muda de funo e passa a ser destino
Coletas seguintes copiam objetos entre sobreviventes ou para a gerao estvel (quando tiverem idade) Um objeto nunca volta ao den Objetos na gerao estvel nunca voltam gerao jovem
12
-
Coletas menores: exemplo Quando o den enche, GC copia objetos alcanveis
Do den (E) para sobrevivente To (St) sempre esvazia o den Do sobrevivente From (Sf) para St sempre esvazia o Sf De Sf para a gerao estvel (T) (dependente de algoritmo) Do den ou Sf para T (se no cabe em St)
E (Eden) Sf St T (Tenured)
E (Eden) St Sf T (Tenured)
13
Depois de1a. coleta
Depois de2a. coleta
Incio:Eden cheio
Eden cheionovamente
GC
GC
Objeto inalcanvel
-
A dana das referncias1. Dois objetos so criados no Eden e
inicializam as referncias a e b com endereos do Eden
ba
IncioEden ST Tenured Gen.SF
14
ba
2. Os objetos sobrevivem primeira coleta e socopiados para uma das duas regies de sobreviventes; as referncias a e b apontam paraos objetos nos novos endereos
Primeira coleta
3. Os objetos sobrevivem a uma segunda coleta. O GC decide copiar o objeto maior para a geraoestvel, enquanto que o objeto menor copiadopara a outra regio sobrevivente
ba
Segunda coleta
Eden
Eden
ST Tenured Gen.SF
ST Tenured Gen.SF
-
Gerao velha (estvel) Consiste principalmente de objetos que
sobreviveram a vrias coletas menores Objetos copiados vrias vezes de um
sobrevivente para a outro Algoritmo de GC usado decide quando
promover um objeto Objetos jovens que recebem referncias de
objetos estveis podem ser emancipados
Um objeto muito grande que no cabe no na rea den criado diretamente na gerao estvel
Pode estar sujeita fragmentao Resultado do algoritmo de GC usado (varia
conforme o tipo de coletor de lixo escolhido)15
Pilha
Gerao estvel
Gerao jovem
-
Coleta maior (completa) Major collection (Full GC) Coletas menores gradualmente enchem a regio estvel
Quando a gerao estvel est cheia, o GC executa uma coleta maior envolvendo todos os objetos de todas as geraes
A coleta maior (completa) pode acontecer antes, se O algoritmo do coletor escolhido for incremental Uma coleta menor no for possvel devido falta de espao
(sobreviventes esto cheios e h mais objetos ativos no Edenque caberiam na regio estvel)
Usa algoritmo mark-sweep (MS) ou mark-compact (MC) Depende do GC escolhido (concorrente, serial, paralelo, etc.) Demora bem mais que uma coleta menor, porm menos
freqente e pode nunca acontecer
16
-
Gerao permanente
17
Consiste de memria alocada por processos no-relacionados criao de objetos Carga de classes (ClassLoader) rea de mtodos (cdigo compilado) Classes geradas dinamicamente (ex: JSP) Objetos nativos (JNI)
Coletas de lixo so muito raras Usa algoritmo Mark-Sweep (com compactao quando cheio) Pode-se desligar a coleta de lixo nesta gerao: -Xnoclassgc Em MacOS X, existem uma gerao imortal: parte da gerao
permanente compartilhada e no afetada por coleta de lixo
No faz parte do heap total controlado pelas opes Xmx e Xms da mquina virtual Usa opes prprias XX:MaxPermSize
-
3. Configurao de memria H vrias opes para configurar o tamanho das
geraes, do heap total e da geropermanente Tambm possvel determinar o tamanho das pilhas
de cada thread Os ajustes pode ser realizados
De forma absoluta, com valores em bytes De forma relativa, com percentagens ou relaes de
proporcionalidade 1:n De forma automtica (usando ergonmica) baseada
em metas de performance
18
-
Tamanho absoluto do heap total
19
Heap total = gerao jovem + gerao estvel No inclui gerao permanente (configurada parte)-Xmx[k|m|g] Tamanho mximo do heap total Default*: -client: 64MB; -server: memria fsica ou 1GB)-Xms[k|m|g] Tamanho mnimo do heap total Default*: -client: 4MB; -server: 1/64 memria fsica ou 1GB)
Exemplos de usojava -Xmx256m -Xms128m ... heap ocupar espao entre 128 e 256 megabytes. java -Xmx256m -Xms256m ... heap ocupar exatamente 256 megabytes (tamanho fixo). Evita
que a JVM tenha que calcular se deve ou no aumentar o heap.* No dependa dos defaults: costumam variar entre plataformas, verses, fabricantes
-
Tamanho da gerao permanente A gerao permanente (onde classes compiladas so guardadas)
no faz parte do heap total Pode ser necessrio aument-la em situaes em que h uso de
reflexo e gerao de classes (ex: aplicaes EJB e JSP)
-XX:PermSize=[k,m,g] Define o tamanho inicial da gerao permanente
-XX:MaxPermSize=[k,m,g] Define o tamanho mximo da gerao permanente. Caso o sistema precise de mais espao que o permitido nesta opo,
causar OutOfMemoryError. Exemplos
java -XXPermSize=32m -XX:MaxPermSize=64m ... Aloca inicialmente 32 megabytes para a gerao permanente,
expansvel at 64 megabytes
20
-
Gerao jovem: tamanho absoluto Gerao jovem menor causa coletas pequenas mais freqentes Gerao jovem maior mais eficiente pois coletas sero mais raras
Mas se ocorrerem iro demorar mais, alm de reduzirem o espao para a gerao velha (o que pode causar coletas demoradas freqentes)
Para alterar o tamanho da gerao jovem, use as opes-XX:NewSize=[k,m,g] Define o tamanho mnimo da gerao jovem
-XX:MaxNewSize=[k,m,g] Define o tamanho mximo da gerao jovem
Exemplos de usojava -XX:NewSize=64m -XX:NewSize=64m ... Define um tamanho fixo de 64 megabytes para a gerao jovemjava -XX:NewSize=64m -XX:NewSize=64m ... Define mnimo de 64 MB e mximo de 128MB para a gerao jovem
21
-
Tamanho da pilha de cada thread Cada thread tem uma pilha
A pilha dividida em quadros (frames) para cada mtodo cujos dados no so compartilhados
Uma pilha grande evita StackOverflowError, porm se a aplicao tiver muitos threads (ex: servidores) a memria total pode ser consumida de forma ineficiente levando a OutOfMemoryError. Reduza o tamanho da pilha, havendo muitos threads, e teste a
ocorrncia de erros StackOverflowError. O tamanho de cada pilha pode ser definido com a opo
-Xss=[k,m,g] Define o tamanho da pilha (de cada thread)
Exemplos de usojava -Xss128k ... Altera o tamanho da pilha de cada thread para 128 quilobytes
22
-
-XX:NewSize
diferena max-min
diferena max-min
diferena max-min
Resumo:ajustes de memria
Valores de ajuste
absolutos
Heap: geraojovem
Heap: geraoestvel
Heap: geraopermanente
Tamanhomnimo
do heap-Xms +
-XX:MaxNewSize
Tamanho doheap total mximo
-Xmx
-XX:PermSize
-XX:MaxPermSize
23
Tamanho da pilha reservada
para cada thread-Xss
...Pilha
-
Tamanho relativo do heap real
24
Esses parmetros influenciam a JVM a aumentar ou diminuir o heap dentro da faixa -Xms/-Xmx Se Xms for igual a Xmx eles no sero considerados-XX:MinHeapFreeRatio= Define a percentagem mnima do heap que precisa estar
disponvel aps uma coleta. Default* = 40% (Client JVM) Se aps uma coleta o heap disponvel no corresponder a no
mnimo esse valor, a JVM aumentar o espao do heapproporcionalmente at alcanar a meta ou atingir o limite
-XX:MaxHeapFreeRatio= Define a percentagem mxima do heap que pode estar
disponvel aps uma coleta. Default* = 70% (Client JVM) Se aps uma coleta o heap disponvel for maior que este valor,
a JVM ir reduzir o espao do heap (reduz uso de memria) at alcanar a meta ou atingir o limite mnimo * valores default variam
entre plataformas/JVMs
-
Exemplo: crescimento do heapjava -Xms30m -Xmx100m
-XX:MinHeapFreeRatio=50-XX:MaxHeapFreeRatio=60 ...
25
utilizao do heapaumentou para 20MB
-Xmx: 100m(heap mximo)
-Xmx: 100m(heap mximo)
-Xms: 30MB (heap inicial)
33,3% free
66,7% used
Aumento do espao reservado ao heap
heap utilizado20MB
50% free
50% used
-
Exemplo: reduo do heapjava -Xms30m -Xmx100m
-XX:MinHeapFreeRatio=50-XX:MaxHeapFreeRatio=60 ...
-Xmx: 100m(heap mximo)
-Xmx: 100m(heap mximo)
26
Espao atualmente reservado ao heap
utilizao do heapcaiu para 20MB
75% free
25% used
Reduo do espao reservado ao heap
heap utilizado20MB
60% free
40% used
-
Conseqncias O ajuste do tamanho do heap o fator que tem o maior
impacto na performance da coleta de lixo geral Os valores atribudos ao heap inicial e heap mximo so valores
limite: a mquina virtual ir procurar utilizar a memria da forma mais eficiente, s ocupando o espao realmente necessrio
Aplicaes que variam o heap com freqncia podero melhorar a performance ajustando os parmetros de redimensionamento para refletir melhor o comportamento da aplicao
Pode-se definir -Xms and -Xmx para o mesmo valor, evitando o redimensionamento a cada coleta Aumenta a previsibilidade da aplicao Remove uma deciso da mquina virtual: no ser preciso
recalcular o uso do heap a cada coleta, mas a mquina virtual no poder compensar se escolha for mal feita.
27
-
Proporo gerao jovem/velha
28
-XX:NewRatio=n Define a proporo 1:n entre a gerao jovem e a gerao velha.
A gerao jovem ocupar 1/(n+1) do espao total do heap.
Valores default dependem do servidor usado No JVM Cliente* (opo -client) a relao 1:8 (NewRatio=8)
No JVM Servidor* (opo server) a relao 1:2 (NewRatio=2)
Exemplo de alteraojava -XX:NewRatio=3 ... n 3, ento a relao 1:3, ou seja, a gerao velha ser 4
vezes a gerao jovem. A gerao jovem ocupar 25% do heap.
Jovem EstvelHeap total
1/3 2/3
Jovem Estvel
1/9 8/9
Heap total
* caso tpico valores default variam entre plataformas
-
Garantia da gerao jovem Young Generation Guarantee [Sun 05] (YGG)
Reserva prvia de espao na gerao velha (estvel) No realizada em coletores paralelos
Para garantir uma coleta menor realizada com sucesso na hipteseem que todos os objetos estejam ativos, preciso reservar memria livre suficiente na gerao estvel para acomodar todos os objetos. O espao poder nunca ser usado: idealmente, os objetos sero
copiados do den e sobrevivente origem para o sobrevivente destino Mas no h garantia que todos os objetos cabero no sobrevivente.
O espao reservado pressupe o pior caso: igual ao tamanho do den mais os objetos no sobrevivente origem. No havendo como reservar o espao, ocorrer uma coleta completa.
Devido YGG, um den maior que metade do espao do heapcomprometido inutiliza as vantagens da Generational GC: apenas coletas maiores iriam ocorrer.
29
-
Conseqncias
30
Gerao jovem maior causa Menos coletas menores, porm com pausas maiores Gerao velha menor para um heap de tamanho limitado: aumentar a
freqncia de coletas maiores (mais lentas pausas maiores) Gerao jovem menor causa
Maior freqncia de coletas menores, de pausas curtas Gerao velha maior, o que pode adiar coletas maiores (que,
dependendo da aplicao, podem nunca ocorrer) Como escolher?
Analise a distribuio dos objetos alocados e estabilizados (tenured) durante a vida da aplicao. No ajuste se no for necessrio.
A menos que sejam detectados problemas com pausas longas ou muitas coletas maiores, aloque o mximo de memria gerao jovem
Veja se a garantia da gerao jovem (YGG) alcanada (no aumente alm da metade do espao usado do heap)
Alocao de objetos pode ocorrer em paralelo, ento aumente medida em que houver mais processadores.
-
Proporo den/sobreviventes
31
-XX:SurvivorRatio=n Proporo entre espaos sobreviventes e o den. O nmero
refere-se ao espao ocupado pelos dois espaos sobreviventes. Uma relao 1:n reserva 1/(n+2) do espao da gerao jovem
para cada sobrevivente
Default* n=25 (Client JVM; cada sobrevivente ocupa 1/27 do espao total da gerao jovem); n=30 (Server)
Exemplojava -Xmx=100m -XX:NewRatio=3 -XX:SurvivorRatio=3
127 25/27
gerao jovem
127
S1 denS2
3/5 1/5
den S1 S2 Estvel
1/5
1/4 3/475 MB mx25 MB mx
15 MB mx 5 MB mx (cada)
* valores default variam entre plataformas
-
Conseqncias Sobrevivente muito grande
Desperdcio de espao (um est sempre vazio) Coletas mais freqentes no den
Sobrevivente muito pequeno Enche muito rpido ou no cabe objetos, que so copiados diretamente
para a gerao velha Enche gerao velha mais rapidamente: +coletas maiores
A cada coleta, a JVM define o nmero de vezes (threshold) que um objeto pode ser copiado (entre sobreviventes) antes de ser promovido gerao estvel. O objetivo manter os sobreviventes cheios pela metade. Isto pode ser
modificado com -XX:TargetSurvivorRatio (default=50) A opo -XX:+PrintTenuringDistribution mostra esse valor e as idades
dos objetos na gerao estvel (velha). O valor mximo pode ser modificado com -XX:MaxTenuringThreshold
(default=31); se for zero objetos so promovidos na primeira coleta
32
-
3. Seleo do coletor de lixoH quatro coletores pr-configurados no J2SE 5.01. Serial collector (default em -client, SGC)
Ative com a opo -XX:+UseSerialGC2. Throughput collector (default em -server, TGC)
Ative com a opo -XX:+UseParallelGC3. Mostly-concurrent low pause collector (CMS)
Ative com a opo -XX:+UseConcMarkSweepGC4. Incremental (train) low pause collector (Train)
Ative com a opo -XX:+UseTrainGC Cada coletor usa uma combinao de algoritmos
disponveis otimizados para situaes distintas possvel configurar e combinar algoritmos diferentes
33
-
Algoritmos utilizados Algoritmos diferentes so usados para as diferentes
geraes e em plataformas multiprocessadas Gerao jovem
(1) Coletor serial (copying algorithm) - default(2) Coletor paralelo (concurrent copying algorithm)(3) Coletor paralelo de alta eficincia (scavenge)
Gerao estvel(4) Coletor mark-compact serial - default(5) Coletor mark-sweep concorrente (6) Coletor train incremental
Coletores pr-configurados combinam algoritmos e permitem ajustes e alteraes na configurao default
34
-
Coleta incremental (Train GC) Divide a velha gerao em vages (blocos de memria) e trens
(conjuntos de blocos) e realiza coletas de alguns blocos sempre que possvel, evitando parar a aplicao Mas no um algoritmo de tempo real, pois no possvel determinar
um limite mximo de pausas, nem saber quando ocorrem, nem h como impedir que todos os threads parem ao mesmo tempo
Impe alto custo sobre a performance: baixa eficincia (throughput) Para ativar use -XX:+UseTrainGC ou -Xincgc
Este coletor parou de ser atualizado na verso 1.4.2.
35
Gerao jovem
Gerao permanente
Gerao estvelusando train
algorithm
trens
vages
-
Coleta da gerao jovem Os algoritmos so todos de cpia Todos param o mundo A principal diferena ocorre em
sistemas multithreaded No coletor default, todos os threads so
interrompidos e um thread executa o algoritmo de cpia serial
Nos coletores paralelos, todos os threads so interrompidos e vrios threads executam um algoritmo de cpia concorrente
A pausa provocada em um coletor paralelo diminui com o aumento do nmero de processadores paralelos
Coletas menores (freqentes)
Pausa para
coleta
ColetorSerial
ColetorParalelo
36
-
Coleta da gerao estvel
37
Fragmentao Coletor serial mark-compact
compacta o espao Coletor concorrente mark-sweep
s compacta se espao acabar (alocao realizada durante coletas menores ser mais cara)
Quatro etapas do coletor concorrente1. Initial mark (stop-the-world,
um thread)2. Mark/pre-clean (paralelo, um thread)3. Remark (stop-the-world,
um ou mais threads)4. Sweep/reset (paralelo, um thread)
Coletas maiores (infreqentes)
Pausa
1. Initial mark
2. Mark &pre-clean
3. Remark
4. Sweep& reset
Mark-CompactSerial
Mark-SweepConcorrente
-
Coletores pr-configurados Serial (-XX:+UseSerialGC*): ideal para sistemas monoprocessados
Gerao jovem: coletor de cpia (1) (default) Gerao estvel: coletor mark-compact (4) (default)
Paralelo com eficincia mxima (-XX:+UseParallelGC) Gerao jovem: coletor de cpia concorrente de alta eficincia (3) Gerao estvel: default (4) (mark-compact serial)
Paralelo com pausas mnimas (-XX:+UseConcMarkSweepGC) Gerao jovem: default (1) (coletor de cpia serial);
verso concorrente (2) pode ser ligada com -XX:+UseParNewGC Gerao estvel: coletor mark-sweep concorrente (5) (com
compactao apenas quando memria cheia)
Incremental (-XX:+UseTrainGC) Gerao jovem: default (1) (cpia serial) ou -XX:+UseParNewGC (2) Gerao estvel: algoritmo train incremental (6)
38*Os parmetros XX:+Use*GC no devem ser combinados
-
Opes de paralelismo
39
-XX:+UseParNewGC Com esta opo a JVM usar um coletor de cpia paralelo (2)
para a gerao jovem. Esta opo s pode ser usada com os coletores que no
especificam um algoritmo para a gerao jovem: XX+:UseTrainGC ou XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled Usada apenas no coletor CMS Com esta opo a remarcao (remark) feita em paralelo,
diminuindo as pausas. Requer o uso das opes -XX:+UseParNewGC e
-XX:+UseConcMarkSweepGC-XX:ParallelGCThreads=n (Default: no. threads disponveis)
Define o nmero de threads que sero usados pelo coletor paralelos da gerao jovem
-
Agendamento de coleta
40
Uma coleta concorrente deve iniciar e terminar antesque a gerao estvel fique cheia Difere do coletor serial que inicia quando a gerao enche
Para saber quando iniciar, o coletor mantm estatsticas para estimar o tempo que falta antes da gerao estvel encher e o tempo necessrio para realizar a coleta As suposies so conservadoras
Uma coleta concorrente tambm iniciar assim que a ocupao da gerao estvel passar de um certo limite Este valor pode ser alterado com a opo-XX:CMSInitiatingOccupancyFraction=nnonde nn a % do espao ocupado antes da coleta (0-100)
O valor inicial aproximadamente 68% do heap.
-
Modo incremental: CMS Vrias opes permitem diminuir pausas quando o CMS
for usado, atravs do modo incremental. As principais opes so:-XX:+CMSIncrementalMode (default: desabilitado) Habilita modo incremental-XX:+CMSIncrementalPacing (default: desabilitado) Permite ajuste automtico do ciclo com base em estatsticas
-XX:CMSIncrementalDutyCycle=n (default: 50) Percentagem de tempo (0-100) entre coletas menores em que o
coletor concorrente pode executar. Se pacing automtico habilitado, este o valor inicial.-XX:CMSIncrementalDutyCycleMin=n (default: 10) Percentagem (0-100) limite inferior do ciclo se pacing habilitado
Veja as vrias outras opes do CMS na documentao
41
-
TGC vs. CMS
42
TGC: Parallel Collector, a.k.a Throughput Collector Objetivo: mxima eficincia com eventuais pausas Aplicaes que usam esse coletor raramente realizam coletas
maiores; quando realizam, no tm problema se o sistema parar Importante que coletas menores sejam rpidas (so sempre
realizadas em paralelo) e eficincia a melhor possvel
CMS: Mostly-Concurrent Collector, a.k.a ConcurrentMark-Sweep (CMS) ou Low Latency Collector Objetivo: mnimo de pausas com eventual perda de eficincia Coletas maiores, apesar de pouco freqentes, podem impor
pausas muito longas (principalmente com heaps grandes) Este coletor diminui as pausas da coleta maior, fazendo rode em
paralelo com a aplicao principal (que fica mais lenta) Duas pequenas pausas da mesma ordem das coletas menores
(normalmente configuradas em paralelo tambm).
-
TGC vs. CMSHigh throughput vs. Low latency-XX:+UseParallelGC vs. -XX:+UseConcMarkSweepGC
com -XX:+UseParNewGC
Menos tempo total dedicado coletade lixo (eficiente)
Ocasional pausalonga (coleta na
gerao estvel serial e usa um
nico thread)
Alocao eficientenas duas geraessem fragmentao
100% GC
100% GC
33%* a 100% GC
Mais tempo total dedicado a GC(ineficiente)
Parcialmente incremental; pausas bem curtas
Pausas na nova gerao mais longas (alocao na gerao estvel mais cara devido fragmentaao)
100%GC
100%GC
100%GC
43* Neste exemplo, com 3 threads
-
Quando a escolha de um coletor de lixo importa para o usurio?
Para muitas aplicaes ele no faz diferena GC realiza pausas de pouca durao e freqncia.
Mas em sistemas grandes, pode ser significativo Compensa escolher o coletor de lixo correto e ajust-lo
Para maior parte das aplicaes o SerialGC adequado Os outros tm overhead e so mais complexos Se uma aplicao no precisa do comportamento especial de um
coletor alternativo, deve usar o coletor serial
Em grandes aplicaes com muitos threads, muita memria e muitos processadores, o coletor serial provavelmente no ser a melhor escolha Neste caso, a escolha inicial deve ser o ParallelGC (TGC)
44
-
Quando usar
45
SGC (SerialGC) Aplicao tpica, um processador, menos de 2GB de RAM
TGC (ParallelGC) Muitos threads alocando objetos (grande gerao jovem,
adiando ou evitando coleta estvel) Performance aumenta proporcionalmente ao nmero de
processadores paralelos Aplicao que tem que ser a mais eficiente possvel
CMS (ConcMarkSweepGC) Pode compartilhar recursos do processador com o coletor de
lixo enquanto a aplicao est executando Muitos dados de vida longa (grande gerao estvel) Requerimento de pausas mnimas (aplicaes interativas)
Train (TrainGC) Requerimento de pausas mnimas; aceita eficincia baixa
-
4. Monitorao de aplicaes Para ajustar os parmetros configurveis da mquina
virtual, preciso realizar medies Vrios parmetros da mquina virtual HotSpot fornecem
informaes teis Ferramentas grficas mostram o comportamento da mquina
virtual e sua alocao/liberao de memria
preciso saber O que ajustar e como ajustar O objetivo do ajuste (menos pausas, mais eficincia) As conseqncias do ajuste
Pode-se tambm utilizar ajustes automticos Java 5.0 Ergonomics
46
-
Por que ajustar? Metas desejveis: menos pausas e mais
eficincia de processamento (throughput) Melhorar uma pode piorar a outra
Eficincia (capacidade de processamento) a percentagem de tempo total no gasta com
coleta de lixo Inclui tempo gasto com alocao Se a eficincia for maior que 95%, geralmente no
vale a pena fazer ajustes na JVM Pausas
Tempo em que uma aplicao parece no responder porque est realizando coleta de lixo
47
-
Informaes sobre as coletas
48
Pode-se obter informaes sobre quando ocorrem coletas e como isto afeta a memria usando a opo-verbose:gc Imprime informaes bsicas sobre as coletas (maiores e
menores) de lixo para a sada padro-Xloggc: Usado com verbose:gc grava a informao no arquivo
especificado (importante para ferramentas de anlise de logs)
Exemplos de usojava verbose:gc aplicacao.Main Imprime informaes de coleta na sada padrojava verbose:gc
Xloggc:aplicacao.gc aplicacao.Main Imprime informaes de coleta no arquivo de texto aplicacao.gc
-
Sada de -verbose:gc Exemplo de sada de grande aplicao servidora
[GC 325407K->83000K(776768K), 0.2300771 secs] [GC 325816K->83372K(776768K), 0.2454258 secs] [Full GC 267628K->83769K(776768K), 1.8479984 secs]
A sada mostra duas coletas menores e uma coleta maior Os nmeros antes e depois da seta (325.407K->83.000K) indicam o
tamanho total de objetos alcanveis antes e depois da coleta Depois de pequenas coletas, a contagem inclui objetos que no esto
necessariamente alcanveis mas que no puderam ser coletados O nmero entre parnteses (776.768K) o total de espao disponvel
(heap total usado menos um dos espaos de sobreviventes e semcontar o espao da gerao permanente)
As coletas menores levaram em mdia 0,24 segundos A coleta maior levou quase dois segundos
49
-
Informaes mais detalhadas-XX:+PrintGCDetails
Esta opo faz com que a VM imprima mais detalhes sobre a coleta de lixo, como variaes sobre o tamanho das geraes aps uma coleta.
til para obter feedback sobre freqncia das coletas e para ajustar os tamanhos das geraes
Exemplo de uso e resultadojava -XX:+PrintGCDetailsGC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K-133633K (261184K), 0.0459067 secs]]
No parece muito H ainda como obter mais detalhes...
50
-
Mais detalhes
51
Tempo transcorrido e distribuio de objetos durante a aplicao-XX:+PrintGCTimeStamps Imprime carimbos de tempo relativos ao incio da aplicao.-XX:+PrintTenuringDistribution Detalhes da distribuio de objetos transferidos para a rea estvel. Pode ser usado para estimar as idades dos objetos que sobrevivem
gerao jovem e para descrever a vida de uma aplicao. Exemplos de uso
java -verbose:gc -XX:+PrintGCDetails-XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution
Sada5.350: [GC Desired survivor size 32768 bytes,
new threshold 1 (max 31)- age 1: 57984 bytes, 57984 total- age 2: 7552 bytes, 65536 total756K->455K(1984K), 0.0097436 secs]
-
Ferramentas: monitorao JMX
52
O prprio J2SDK possui uma ferramenta simples que fornece informaes grficas sobre a memria usando JMX (Java Management Extensions) Programvel e extensvel
Para habilitar o agente JMX e configurar sua operao, preciso definir algumas propriedades do sistema ao iniciar a mquina virtual
As propriedades podem ser passadas em linha de comando da forma> java Dpropriedade> java Dpropriedade=valor
Se um valor no for fornecido, a propriedade utilizar um valor default (se houver e se for aplicvel)
-
Propriedades JMX da JVMAs duas principais propriedades so com.sun.management.jmxremote
Habilita o agente remoto JMX Permite monitorao local atravs de um conector JMX usado
pela ferramenta jconsole Os valores podem ser true (default) ou false.
com.sun.management.jmxremote.port=valor Habilita o agente remoto JMX Permite monitorao remota atravs de um conector JMX de
interface pblica disponibilizada atravs de uma porta O valor deve ser o nmero da porta Esta opo pode requerer outras propriedades (veja tabela 1 em
/docs/guide/management/agent.html (documentao J2SE 5.0*)
53* [SDK]
-
Como habilitar o agente JMX para monitorao local
1) Execute a classe ou JAR da aplicao via JVM passando a propriedade jmxremote> java Dcom.sun.management.jmxremote pacote.MainClass> java Dcom.sun.management.jmxremote jar Aplicacao.jar
2) Obtenha o nmero do processo JVM*> jps3560 Programa (mquina virtual)3740 pacote.MainClass (use este nmero!)3996 Jps
3) Inicie o jconsole com o nmero do processo Use o mesmo usurio que iniciou a aplicao> jconsole 3740
54* jps uma das ferramentas do pacote experimental jvmstat 3.0, que faz parte do J2SDK 5.0
-
jconsole: memria Execute oGarbage Collector
55
Selecione a rea do heap
desejada
-
Monitorao remota
56
Para monitorao em tempo de produo, recomenda-se uso remoto (devido ao overhead da aplicao)
Para configurar, preciso obter uma porta de rede livre A porta ser usada para configurar acesso remoto via RMI O sistema tambm criar no registro RMI um nome jmxrmi
Alm da porta de acesso, preciso configurar propriedades de autenticao, dentre outras Para configurao do acesso remoto e outras informaes, veja
/docs/guide/management/agent.html (documentao J2SE 5.0*) Tambm pode-se obter acesso programtico
Para executar o jconsole remotamente, informe o nome da mquina e a porta> jconsole alphard:3740
* [SDK]
-
Monitorao concisa: jstat
57
Jstat ferramenta do pacote experimental jvmstat Obtm dinamicamente estatsticas de uso das geraes, de
compilao, de carga de classes em tempo real
Para executar, use jstat jvmid Exemplos
> jps13829 Java2Demo.jar1678 Jps.jar
> jstat -gcutil 13829S0 S1 E O P YGC YGCT FGC FGCT GCT12.44 0.00 27.20 9.49 96.70 78 0.176 5 0.495 0.67212.44 0.00 62.16 9.49 96.70 78 0.176 5 0.495 0.67212.44 0.00 83.97 9.49 96.70 78 0.176 5 0.495 0.6720.00 7.74 0.00 9.51 96.70 79 0.177 5 0.495 0.673
Geraes
no. coletas menores
no. coletas maiores
Tempo de coletas menores, completas e total
-
Visual GC
58
Visual GC a ferramenta visual do pacote experimental jvmstat (distribudo com o SDK 5.0) Mostra geraes, coletas, carga de classes, etc. graficamente preciso baixar o Visual GC separadamente:
http://java.sun.com/performance/jvmstat/visualgc.html
Para rodar, preciso ter o no. do processo da aplicaoa monitorar e o perodo de coleta de amostras (em ms)
Exemplo: monitorao local> jps21891 Java2Demo.jar1362 Jps.jar> visualgc 21891 250
Para acesso remoto, preciso obter o nmero do processo remoto e acrescentar o nome de domnio
> visualgc [email protected] 250
-
Exemplo: Visual GC
59
-
Outras ferramentas GC Portal (java.sun.com/developer/technicalArticles/Programming/GCPortal)
Aplicao J2EE que gera grficos e estatsticas Requer instalao em um servidor
GCViewer (www.tagtraum.com) Analisa documentos de texto criados com Xloggc:arquivo Mostra comportamento das geraes e outras informaes Pode executar em tempo real
Profilers Vrios profilers comerciais e gratuitos oferecem informaes e
capacidade de monitorao em tempo real da JVM Comerciais: JProbe, OptimizeIt, JProfiler Gratuitos: NetBeans Profiler, Eclipse Profiler, JRat, EJB,
Cougaar, etc.
60
-
Exemplo: GC Viewer
61
http://www.tagtraum.com/
Uma coleta maior
Vrias coletas menores
Informaes detalhadas
(pausas, throughput,
memria)
Dados carregados de arquivo gerado com a opo da JVMXloggc:normal.gc
Ferramenta gratuita de
-
5. Ajuste automtico: ergonomics O objetivo da ergonmica obter a melhor performance
da JVM com o mnimo de ajustes de linha de comando Mais fcil de ajustar (ajuste manual difcil) Uso mais eficiente dos recursos
A ergonmica busca obter, para uma aplicao, as melhores selees de Tamanho de heap Coleta de lixo Compilador de tempo de execuo (JIT)
Ajustes baseados em metas Metas de pausa mxima Capacidade de processamento desejado Alvo: aplicaes rodando em servidores grandes (-server)
62
-
Server class machine detection Quando uma aplicao inicia, o ambiente de execuo
tentar descobrir se est rodando em uma mquina servidor ou cliente Se tiver pelo menos duas CPUs e pelo menos 2GB de memria
fsica, ser considerada servidora, caso contrrio, cliente
Se estiver em mquina servidora, inicia a JVM Server Inicia mais lentamente, mas com o tempo roda mais rpido
Se estiver em mquina cliente, usa a JVM Client Configurada para melhor performance em ambientes cliente
JVM selecionada ser usada e ser default Sempre ser usada a no ser que seja especificado outra
atravs das opes server ou client
63
-
Como funciona
64
Usurio especifica Meta de pausa mxima Meta de eficincia mnima Uso mnimo/mximo de memria
Coletor de lixo ajusta automaticamente Aumenta ou diminui tamanho das geraes jovem,
espaos sobreviventes, gerao estvel Altera poltica de promoo para gerao estvel
No garante que metas sero cumpridas So metas, no garantias Como garantir? Seguir estratgias recomendadas
-
Coletor paralelo: ergonomics As opes abaixo requerem -XX:+UseParallelGC-XX:MaxGCPauseMillis=valor em ms JVM tentar manter pausas mais curtas que o valor especificado Tem precedncia sobre XX:CGTimeRatio-XX:GCTimeRatio=n Define meta de eficincia (throughput). A eficincia
n um valor normalizado que mede a proporo de tempo dedicado aplicao da forma 1:n.
Exemplo: se n for 19, a JVM reservar aplicao 20 (19 + 1) vezes mais tempo que a coleta de lixo (coleta ter 5% do tempo)
Tem menos precedncia que -XX:MaxGCPauseMillis.
tempo de aplicaotempo de coleta de lixo
11 + n
= 1
65
-
Coletor paralelo: ergonomics
66
-XX:+UseAdaptiveSizePolicy Com esta opo presente, a JVM coleta dados e se baseia
neles para redimensionar as geraes jovem e antiga Esta opo automaticamente ligada se a opo
XX:+UseParallelGC estiver presente. -XX:+AggressiveHeap
Implica no uso das opes XX:+UseParallelGC e XX:+UseAdaptiveSizePolicy
No pode ser usada com XX:+UseConcMarkSweepGC Se esta opo estiver presente, a mquina virtual ir configurar
vrios parmetros buscando otimizar tarefas longas com uso intenso de memria. Usar como base informaes como quantidade de memria disponvel e nmero de processadores.
Esta opo s recomendada para servidores dedicados. Requer pelo menos 256MB de memria fsica
-
Ergonomics: estratgias
67
1.1 Inicialmente, no escolha um valor mximo para o heap (-Xmx)1.2 Escolha uma meta de eficincia (throughput) que seja suficiente
para sua aplicao Em uma situao ideal, o sistema aumentar o heap at atingir um
valor que permitir alcanar a meta de eficincia desejada.
2.1 Se o heap alcanar o limite e o throughput no tiver sido alcanado2.2 Ento escolha um valor mximo para o heap (menor que a
memria fsica da mquina) e rode a aplicao de novo. Se ainda assim a meta de eficincia no for atingida, alta demais para
a memria disponvel na plataforma
3. Se a meta de eficincia foi alcanada mas as pausas ainda soexcessivas, estabelea uma meta de tempo mximo para pausas Isto pode fazer com que a meta de eficincia no seja mais alcanada Escolha valores que garantam um tradeoff aceitvel
-
Concluses
68
Mquinas virtuais HotSpot implementam diversos algoritmos clssicos de coleta de lixo Todos baseados em heap dividido em geraes Pr-configurados para situaes, plataformas e usos diferentes Permitem ajustes manuais ou automticos
O ajuste adequado da JVM em grandes aplicaes pode trazer ganhos dramticos de performance Ajuste pode ser simplesmente selecionar a JVM (server ou cliente)
ou definir diversos complexos parmetros manualmente
Para ajustar parmetros (mesmo automticos) preciso conhecer funcionamento dos algoritmos Configurao manual (ex: tamanho de heap) impe conseqncias
que tm impactos em outras reas da performance Metas de ajuste automtico afetam outras metas ou parmetros
-
6. Apndice: Class data sharing (CDS) Recurso das JVM Client 5.0 para reduzir o tempo de
incio de pequenas aplicaes Durante a instalao, criado um arquivo que ser
compartilhado pelas JVMs que estiverem executando Durante a execuo, mltiplas JVMs compartilharo classes na
memria, evitando carreg-las novamente
Para suportar este recurso, preciso Usar uma plataforma que no seja Windows 95/98/ME Usar o JVM Client e coletor de lixo serial (default em desktops)
Opes da JVM relacionadas-Xshare:[on|off|auto] liga/desliga ou usa CDS se possvel-Xshare:dump gera novamente o arquivo. preciso primeiro
apagar o arquivo em $JAVA_HOME/client/classes.jsa69
-
Fontes de referncia[SDK] Documentao do J2SDK 5.0[Sun 05] Tuning Garbage Collection with the 5.0 Java Virtual Machine, Sun, 2005[HotSpot] White Paper: The Java HotSpot Virtual Machine, v1.4.1. Sun, 2002.[Apple 04] Java Development Guide for MacOS X. Apple, 2004[Gotry 02] K. Gottry. Pick up performance with generational garbage collection.
JavaWorld www.javaworld.com. Jan 2002[Gupta 02] A. Gupta, M. Doyle. Turbo-charging Java HotSpot Virtual Machine, v1.4
to Improve the Performance and Scalability of Application Servers. Sun, 2002.http://java.sun.com/developer/technicalArticles/Programming/turbo
[Nagarajayya 02] N.Nagarajayya, J.S. Mayer. Improving Java ApplicationPerformance and Scalability by Reducing Garbage Collection Times and SizingMemory Using JDK 1.4.1. Sun Microsystems. Nov 2002
[Holling 03] G. Holling. J2SE 1.4.1 boosts garbage collection. JavaWorld. Mar 2003.[Goetz 03] B. Goetz. Java theory and practice: Garbage collection in the HotSpot
JVM. IBM Developerworks. Nov 2003.
70
2005, Helder da Rochawww.argonavis.com.br
Gerncia de Memria em JavaParte II: Monitorao e configurao da mquina virtual HotSpotOtimizao da JVM HotSpotAssuntos abordadosOpes XX da JVM HotSpot1. Arquitetura da HotSpot JVMTodas as VM HotSpot possuemColeta de lixo em Java: breve histriaColetor de lixo serialHotSpot: arquitetura do heapGerao jovemColeta menorColetas menores: algoritmoColetas menores: exemploA dana das refernciasGerao velha (estvel)Coleta maior (completa)Gerao permanente3. Configurao de memriaTamanho absoluto do heap totalTamanho da gerao permanenteGerao jovem: tamanho absolutoTamanho da pilha de cada threadResumo:ajustes de memriaValores de ajuste absolutosTamanho relativo do heap realExemplo: crescimento do heapExemplo: reduo do heapConseqnciasProporo gerao jovem/velhaGarantia da gerao jovemConseqnciasProporo den/sobreviventesConseqncias3. Seleo do coletor de lixoAlgoritmos utilizadosColeta incremental (Train GC)Coleta da gerao jovemColeta da gerao estvelColetores pr-configuradosOpes de paralelismoAgendamento de coletaModo incremental: CMSTGC vs. CMSTGC vs. CMSQuando a escolha de um coletor de lixo importa para o usurio?Quando usar4. Monitorao de aplicaesPor que ajustar?Informaes sobre as coletasSada de -verbose:gcInformaes mais detalhadasMais detalhesFerramentas: monitorao JMXPropriedades JMX da JVMComo habilitar o agente JMX para monitorao localjconsole: memriaMonitorao remotaMonitorao concisa: jstatVisual GCExemplo: Visual GCOutras ferramentasExemplo: GC Viewer5. Ajuste automtico: ergonomicsServer class machine detectionComo funcionaColetor paralelo: ergonomicsColetor paralelo: ergonomicsErgonomics: estratgiasConcluses6. Apndice: Class data sharing (CDS)Fontes de referncia