Especificao de Integrao

Performance de Aplicaes Java

Tuning de JVM 1.0

Pgina 1 de 11

Tuning de JVM

Pgina 2 de 11

Tuning de JVM

ndice
Apresentao 1. Introduo 2. Pblico Alvo 3. Quando utilizar este documento? Parte I Memria e Garbage Collection 4. Memria do Processo JVM 4.1.1 Modelo de Memria da JVM 5. Garbage Collection 5.1.1 Alocao e execuo do garbage collection 5.1.2 Dimenses da Memria Heap 5.1.3 Dimenses da Memria Non-Heap (Permanent Generation) Parte II Ferramentas de Monitoramento 6. JConsole 6.1.1 Executando o JConsole 6.1.2 Overview de Processamento e Memria 6.1.3 Anlise de Memria Heap e Non-Heap 6.1.4 Obter Informaes da JVM 4 4 4 4 5 5 5 6 6 6 7 9 9 9 10 11 11

Pgina 3 de 11

Tuning de JVM

Apresentao
1. Introduo

O objetivo deste documento fornecer informaes bsicas de como a Java Virtual Machine fornecida pela Sun Microsystems organiza seu modelo de memria, como esta memria pode ser monitorada e quais ferramentas, e como poderemos modificar a organizao de tal memria para prover um ganho de performance para a aplicao.

2.

Pblico Alvo
e

Este documento tem como pblico alvo administradores de infraestrutura, arquitetos desenvolvedores de aplicao que rodam na plataforma Java.

3.

Quando utilizar este documento?

Este documento deve ser consultado sempre que houver implantao de aplicaes em novos ambientes ou quando aplicaes sofrerem problemas de performance.

Pgina 4 de 11

Tuning de JVM

Parte I Memria e Garbage Collection

4. Memria do Processo JVM
A Sun foi o primeiro fornecedor da JVM, cuja implementao a mais utilizada. Tambm temos outros fornecedores tais como a IBM e Oracle (Bea - JRockit). A JVM da Sun opera sob a premissa que objetos de curta durao de vida so criados e destrudos muito rapidamente. Para gerenciar a forma de alocao dos objetos a Sun implementou o heap no que foi chamado de geraes, Young Generation e Old Generation, conforme apresentado no tpico seguinte. 4.1.1 Modelo de Memria da JVM Young Generation Old Generation
Non-Heap
Figura 1

den rea onde so criado os objetos novos.

Survivor Space 0 (From) Survivor Space 1 (To) Tenured Space

Memria

Heap

Code Cache Permanent Shared-RW Permanent Shared-RO Permanent

Conforme apresentado acima a JVM fornecida pela Sun divide o heap em duas partes: Old Generation (Tenured Space), e Young Space (New Space). Observe que a gerao Young dividida em trs partes: O den e duas Survivos Spaces, chamadas de From Space e To Space. Objetos so criados no den; quando o den est cheio, objetos ainda em uso so copiados para o From Space; Quando o den fica cheio novamente, os objetos no From Space so copiados para o To Space; e finalmente; se os objetos continuam em uso quando o den fica cheio novamente, ento os mesmos so movidos para a Old Generation (Tenured Space). A imagem abaixo, figura 2, apresenta como os objetos so movidos no heap a cada momento que o den fica cheio.

Figura 2 (Fonte da Figura: Internet)

Pgina 5 de 11

Tuning de JVM
5. Garbage Collection

O pargrafo anterior descreveu o resumo de como os objetos so alocados no heap, para fixar o entendimento segue novamente abaixo todo o processo de maneira um pouco mais detalhada. Ateno: No confundir Garbage Collector com garbage collection. O garbage Collector quem executa o Garbage Collection. 5.1.1 Alocao e execuo do garbage collection Os objetos Java so criados no den Space, dentro da gerao Young. Quando so criados objetos suficientes para preencher o den, ento o Garbage Collector executa uma pequena garbage collection, as vezes chamada de Copy Collection. Neste pequeno garbage collection, o Garbage Collector examina os objetos do den: removendo todos os objetos sem referncia e copiando os objetos em uso para o From Space at que o From Space fique cheio. Desta forma, objetos de vida curta iro morrer no den, enquanto que os objetos sobreviventes sero movidos para o From Space; com isso estamos liberando, pelo menos, o nmero de bytes que compem o contedo do den referente ao tamanho do From Space. Quando o den fica cheio novamente, objetos em uso no From Space so copiados do From Space para o To Space, em teoria. Na pratica a JVM mantm um ponteiro para os Survivo Spaces e a cada vez que um pequeno garbage collection executa, a JVM simplesmente altera os ponteiros, do From Space para o To Space. Quando o den novamente fica cheio, ento quaisquer objetos que ainda esto em uso no To Space so retirados para a gerao Old (Tenured Space). Estes pequenos garbage collections so muito rpidos e eficientes, geralmente variam de dcimos de segundo a centsimos de segundo, a depender do tamanho do heap, e das threads da JVM no serem interrompidas durante estes garbage collections. Quando a gerao Young (den e Survivos) esto cheios, e o Garbage Collector precisa de memria livre, ento executado um garbage collection maior (Full Garbage Collection). Este garbage collection congela todas as threads que esto rodando na JVM e executa o teste de acessibilidade. O teste de acessibilidades resulta na marcao dos objetos em uso no heap, que logo so seguidos por uma varredura de objetos mortos e uma compactao opcional para liberar espao no heap. Garbage collection conhecido tambm como Mark-and-sweep collection, este tipo de garbage collection executa operaes extremamente intensivas de processamento e pode variar no tempo de alguns dcimos de segundo para vrios segundos; H casso em que pode durar at 20 segundos. Portanto, independente de como voc bem tune a JVM para sua aplicao ganhar performance, freqentemente maiores garbage collections podero afetar a performance da aplicao. A esperana da estratgicas de geraes que movendo objetos na gerao Young Generation, objetos de vida curta podem morrer e liberar memria livre, antes de ser movido para a gerao Old (Tenured Space). Geralmente durante todo o tempo, objetos de longa durao iro permanecer na gerao Old, enquanto que objetos de curta durao iro morrer na gerao Young, durante pequenos garbage collection.. 5.1.2 Dimenses da Memria Heap As dimenses dos retngulos da figura 1, com relao s geraes Young e Old, foram propositalmente ajustadas afim de sugerir como que o tamanho de cada rea do heap comumente dimensionado nas atividades de tuning de JVM. Em muitas situaes poder ser observado melhor performance com as seguintes dimenses: A gerao Young um pouco menor que a metade do heap, e cada Survivo Space cerca de 1/8 da gerao Young. Infelizmente, por causa do fato da JVM ser projetada para uma grande variedade de tipos de aplicaes, a configurao padro costuma ser longe da ideal para aplicaes empresariais que suportam centenas de usurios simultaneamente.

Pgina 6 de 11

Tuning de JVM
A configurao padro varia de acordo com o sistema operacional, mas em geral, a gerao Young Generational muito pequena, 32MB ou 64MB, e os Survivo Spaces so somente 1/34 da gerao Young, o que costuma estar entre um pouco menos que 1MB e 2MB. O problema quando vrios usurios acessam a aplicao simultaneamente, causando a carga de vrios objetos em memria, muitos destes objetos que so de vida curta acabam prematuramente sendo carregado na gerao Old, e requer que um maior garbage collection seja necessrio para colet-los. Esta carga prematura na gerao Old, entra em conflito com a estratgica inicial do garbage collection. Lembre-se que quando Eden est cheio, o mesmo no liberado de uma s vez, mas em pedaos, pelo menos, o tamanho do espao de um Survivor Space. Portanto, mesmo que tenhamos um heap de 2GB, haver de ser executado um garbage collection, todo o tempo, para cada megabyte (tamanho do Survivor Space) que criado. Quando a JVM iniciada, voc pode redimensionar a gerao Young, bem como den e os tamanhos dos Survivor Spaces. Conforme havia informado, a preferncia de muitos administradores de sistemas, para tuning de JVM fornecido pela Sun, dimensionar a gerao Young um pouco menos de metade do tamanho do heap, mas no muito menor. De acordo com a especificao JVM, tornando a gerao Young superior a metade do heap a capacidade de executar um pequeno garbage collection (copy collection) fica comprometida, resultando em uma mark-and-sweep (marca-e-varrer) para pequenos garbage collections. Segue abaixo tabela de parmetros para definio dos tamanhos das principais reas do heap.
Parmetro

-XmxNNNm -XmsNNNm -XX:MaxNewSize=NNNm -XX:NewSize=NNNm -XX:SurvivorRatio=n

Descrio Tamanho mximo do heap, onde NNN representa o tamanho do heap e m representa a unidade (m=megabytes ou g=gigabytes) Tamanho mnimo do heap. Geralmente inicio com o mesmo tamanho mximo do heap. Tamanho mximo da gerao Young. Tamanho mnimo da gerao Young. Tamanho dos Survivor Spaces, onde n a relao com tamanho da gerao Young (*).

(*) O tamanho do Survivor Space definido da seguinte forma, o den recebe um numero de unidades especificado pelo SurvivorRatio, enquanto cada Survivor Space recebe uma unidade, por exemplo, se SurvivorRatio receber o valor 6, o dem ter um tamanho de 6/8 da gerao Young enquanto que cada Survivor Space tar o tamanho de 1/8 da gerao Young. Quando NewSize e MaxNewSize forem iguais poderemos aplicar as seguintes frmulas.
den = ((n 2) / (n + 2)) * NewSize Cada Survivor Space = (1 / (n + 2)) * NewSize

Onde n o valor do SurvivorRatio. Segue abaixo alguns exemplos recomendados para configurar heap de 1GB e 2GB.
-Xmx1024m -Xms1024m -XX:MaxNewSize=448m -XX:NewSize=448m -XX:SurvivorRatio=6 -Xmx2048m -Xms2048m -XX:MaxNewSize=896m -XX:NewSize=896m -XX:SurvivorRatio=6

5.1.3

Dimenses da Memria Non-Heap (Permanent Generation) Aps a configurao do heap, deve-se configurar a regio conhecida como non-heap, ou Permanent Space. A Permanent Space faz parte do conjunto de memria utilizada pelo processo da JVM, porm a mesma no impacta no tamanho do heap, por exemplo, a memria que voc solicita para o Permanent Space no utiliza a memria separada para o heap via parmetro XmxNNN. O heap contm instncias de objetos, mas antes de criar os objetos a JVM precisa primeiro abrir os arquivos das classes e carregar o bytecode. Quando a JVM ler o bytecode, ela o armazena na memria Permanent Space (Permanent Generation). Aps carregadas na memria estas classes podem ento serem usadas para criar instncias de objetos no heap, cuja referncia so retornadas ao cdigo chamador.

Pgina 7 de 11

Tuning de JVM
A Permanent Space no deve ser ignorada, porque voc precisa memria suficiente para alocar todas as classes de sua aplicao, isso inclui os arquivos JSP, devido ao fato dos arquivos JSP serem traduzidos para Servlets e compilados em classes Java, e por conseqncia serem carregadas na Perment Space, relacionada a memria do processo JVM em execuo. Se sua aplicao usa muitos arquivos JSP, voc talvez tenha de aumentar o tamanho da Permanent Space. Lembre que uma Permanent Space pequena faz com que o processo da JVM tenha de acessar com mais freqncia o disco rgido para carregar as classes, impactando a performance do processo. Segue abaixo os parmetros de inicializao da JVM para dimensionar a Permanent Space.
Parmetro

-XX:MaxPermSize

-XX:PermSize=NNNm

Descrio Tamanho mximo da Permanent Space, onde NNN representa o tamanho e m representa a unidade (m=megabytes ou g=gigabytes) Tamanho mnimo da Permanent Space.

Pgina 8 de 11

Tuning de JVM

Parte II Ferramentas de Monitoramento

6. JConsole
O JConsole uma ferramenta que acompanha o Java 2 Platform Standard Edition (J2SE), sua finalidade monitorar aplicaes para fins de gerenciamento e suporte. O JConsole no s fornece interface para gerenciamento da JVM local, mas tambm prover suporte a monitoramento e gerenciamento remoto. Atravs da tecnologia JMX, o JConsole executa extensiva instrumentao da JVM, e prover suas informaes de performance, bem como consumo de recursos pelas aplicaes. Ateno: Apesar de ser uma tima ferramenta, infelizmente o JConsole no permite acompanhar o comportamento da memria junto com o grfico de comportamento do garbage collection. Para isso iremos apresentar o VisualGC. 6.1.1 Executando o JConsole O JConsole, assim como as demais ferramentas que acompanham o JDK encontra-se instalado na pasta Bin, conforme imagem abaixo.

Aps execut-lo ser apresentado a tela de seleo de processo e login (quando remoto). Observe que os processos no compatveis para gerenciamento encontram-se desabilitados para seleo, o caso do OC4J (PID 212).

Pgina 9 de 11

Tuning de JVM
6.1.2 Overview de Processamento e Memria Ao entrar no JConsole apresentado a tela abaixo. Observe que nesta tela inicial j temos uma gama de informaes, que mesmo no sendo detalhadas j podem ajudar em nosso Tuning. Heap Memory Usage Por meio deste grfico podemos analisar se os valores de xms e xmx esto suficientes para aplicao. Threads A quantidade de threads simultneas nos ajudar a identificar se a aplicao precisa de refactoring para utilizao de ThreadPool, com processamento de grupos em grupos de threads, evitando com isso a escassez total dos recursos. Classes Atravs da quantidade de classes podemos estimar uma idia o tamanho da Permanent Space. CPU Usage Nos apresenta se os recursos de processamento esto suficientes para a aplicao. Caso a memria e a aplicao estejam ok, talvez seja necessrio um upgrade do processador.

Pgina 10 de 11

Tuning de JVM
6.1.3 Anlise de Memria Heap e Non-Heap Acredito que esta aba contenha as principais informaes para tuning da JVM. Com ela poderemo investigar todas as reas do heap e non-heap, nos ajudando a estimar os corretos valores para as geraes Young, Old e Permanent. Para alternar entre os grficos das diferenets reas de memria basta executar um clique no retngulo verde-claro referente a rea de memria desejada.

6.1.4

Obter Informaes da JVM O JConsole tambm fornece diversas informaes sobre o processo da JVM em anlise. Com ele poderemos investigar quais parmetros foram passados (se foram!) para tuning do processo, bem como recursos de hardware, sistema operacional e garbage collection.

Pgina 11 de 11