Muitos anos atrás um grande mestre nos disse que para se tornar um mestre JEDI era necessário conhecer como funciona o Garbage Collector e como escrever o seu próprio ClassLoader. Como um Padawan dedicado que não media esforços para se tornar um mestre e sem medo de misturar Star Trek com Star Wars, comecei a estudar como fazer tuning em aplicações Java controlando a alocação de memória realizada pela JVM.Recentemente participei de duas consultorias onde foi necessário resolver problemas de performance fazendo uma análise da distribuição de memória entre as áreas geracionais dentro de uma JVM da Sun em execução e avaliar como a atuação do Garbage Collector influenciava a aplicação.
Como parte dos estudos e dos trabalhos de consultoria realizados, consegui dar um pequeno passo em direção à força! Agora compartilho um pouquinho do que aprendi.
Para ter uma ideia de como uma configuração errada da alocação de memória dedicada à JVM (normalmente via parâmetros de linhas de comando -Xms e -Xmx) ou a configuração default pode prejudicar a performance de uma aplicação, basta observar o figura a seguir.
Este gráfico ilustra os momentos e o tempo de execução do Garbage Collector na área Old da memória alocada pela JVM. Alguns tempos são da ordem de 50 a 70 segundos. São tempos que uma aplicação fica congelada enquanto o Garbage Collector realiza a limpeza da memória para liberar espaço. Representa um tempo que certamente incomodará o usuário final durante o uso da aplicação.
Como obter estes dados e otimizar a performance?
No JDK, além das ferramentas tradicionais de linha de comando como javac e java, estão presentes as ferramentas jps, jstat e jstatd. A primeira é equivalente ao comando ps do Unix e permite saber quais processos Java (JVM) estão em execução e o respectivo PID. O segundo permite gerar estatísticas de Garbage Collection e tamanhos da memória ocupada pelas áreas geracionais do Java em execução. A terceira ferramenta faz o mesmo que a segunda ferramenta, mas disponibiliza os dados para acesso remoto via RMI. Muito útil para coletar dados de uma JVM executando remotamente num servidor e acompanhar a partir do desktop do desenvolvedor. O screenshot a seguir ilustra a execução dessa ferramenta via terminal para o demo SwingSet2 presente em qualquer instalação de JDK.
Os detalhes sobre estas ferramentas e o significado de cada informação coletada podem ser obtidos em: Java Virtual Machine Statistics Monitoring Tool (jstat) e Java Virtual Machine Process Status Tool (jps).
Contudo, uma ferramenta muito interessante do pacote jvmstat que não foi incorporada ao JDK é o chamado visualgc (Visual Garbage Collection Monitoring Tool). Esta ferramenta permite visualizar graficamente os mesmos dados disponibilizados pela ferramenta jstat. Assim, torna-se possível perceber a dinâmica do Garbage Collector ao liberar memória dentro das áreas geracionais, além de indicar o tempo de execução de cada garbage collection, os tamanhos de cada área geracional e o espaço alocado a cada momento.Como o visualgc não está presente no JDK, torna-se necessário fazer o download e instalar localmente (muito simples de instalar!). Para executar via linha de comando, basta digitar: visualgc vmid [interval], onde vmid é o PID da JVM desejada obtido via jps e interval é o tempo em milisegundos ou segundos que a ferramenta coleta as informações da JVM e atualiza na tela. Um exemplo de execução desta ferramenta é ilustrada na figura a seguir para o demo SwingSet2 em execução.
Colocar a ferramenta para rodar ou coletar os dados via linha de comando é a parte fácil. Agora vem a parte difícil! Como analisar estas informações e transformar em resultado útil ao melhorar a performance de um aplicação Java? Este é um segredo que os mestres JEDI raramente ensinam! Mas um antigo pergaminho escrito por uma extinta empresa que era a meca dos JEDI revela todos os segredos. Este valioso documento é datado da época do JDK 1.3 e veio sofrendo atualizações ao longo dos anos para as versões atuais de JDK. O texto citado ainda pode ser encontrado na seguinte página (não sabemos até quando!): Tuning Garbage Collection with the 5.0 Java™ Virtual Machine.
Uma leitura cuidadosa do texto antigo, esquecido ou ignorado por muitos e citado acima, permitirá o Padawan e aprendiz de mestre JEDI conhecer detalhes de como usar a força a seu favor e melhorar significativamente a performance de uma aplicação Java. Contudo, nem sempre o caminho da força e conhecimento é fácil! Este caminho exige muito estudo, esforço e dedicação. Mas, cuidado para não cair na tentação do caminho mais fácil da ilusão criada pelos lordes "Microsith".Quem sabe algum dia eu conto alguns segredos sobre como criar ClassLoaders customizados! Até lá boa leitura e bons códigos!
By Spock
http://blog.spock.com.br/
http://twitter.spock.com.br/
http://www.springbrasil.com.br/
Comentários
A arquitetura de class loading, os modelos e áreas de memória onde atua (ou não) o GC e as capacidades atuais de instrumentar uma JVM define o que é maturidade.
Não imagino a quanto anda isso nas outras linguagens da moda, mas sei que se ela roda em cima da uma JVM, vai levar tudo isso pronto, como um sistema operacional da linguagem.
Agora se a linguagem for solo, alguém vai ter que fazer tudo isso para ela...
Parabéns mais uma vez, vc é o cara!
Duas ferramentas que me ajudaram a monitorar o GC, em alguns tunings que realizei, foram:
- Introscope, ferramenta da CA: http://www.ca.com/br/products/product.aspx?id=5779
- YourKit, dica do Ricardo Jun na época: http://www.yourkit.com/
Ambas são pagas.
[]s
Eder
e uma dica sobre boas referencias de garbage collector e classloaders são os pdfs em portugues do livro Arquitetura Java... dá pra baixar esses capitulos de graca aqui http://www.arquiteturajava.com.br
Legal lembrar também que é possível fazer análise de desempenho do GC através do próprio log obtido através de parâmetros da JVM (JVM da sun, -verbose:gc -Xloggc:gc.log). Com esse log e o gcviewer (http://www.tagtraum.com/gcviewer.html) é possível obter o gráfico do GC desde o start da JVM.
Fica a dica.
Parabéns!