Como monitorar o uso de memória Java?
temos uma aplicação j2ee a correr no Jboss e queremos monitorizar o seu uso de memória. Atualmente usamos o seguinte código
System.gc();
Runtime rt = Runtime.getRuntime();
long usedMB = (rt.totalMemory() - rt.freeMemory()) / 1024 / 1024;
logger.information(this, "memory usage" + usedMB);
-
Como posso ter a minha curva de uso da memória?
- Qual é o problema com o gc explícito()? Eu não me importo com pequenos problemas de desempenho que podem acontecer com GC explícito() e que eu estimaria em 1-3%. O que eu preciso é de memória e monitor thread que me ajuda na análise do nosso sistema no site do cliente.
14 answers
Se quiser realmente ver o que se passa na memória VM, deve usar uma boa ferramenta como VisualVM. Este software é livre e é uma ótima maneira de ver o que está acontecendo.
Nada é realmente "errado" com chamadas GC() explícitas. No entanto, lembre-se que quando você chama gc() você está "sugerindo" que o coletor de lixo corra. Não há nenhuma garantia de que ele será executado no momento exato em que você executar esse comando.
Existem ferramentas que lhe permitem monitorizar o uso da memória VM. O VM pode expor as estatísticas de memória usando o JMX . Você também pode imprimir as estatísticas do GC para ver como a memória está a funcionar ao longo do tempo.
Sistema De Invocação.gc () pode prejudicar o desempenho do GC porque os objetos serão movidos prematuramente das novas para as velhas gerações, e referências fracas serão apagadas prematuramente. Isso pode resultar em diminuição da eficiência de memória, tempos de GC mais longos, e perda de cache acertos (para caches que usam refs fracos). Concordo com o seu consultor: sistema.gc() é mau. Eu iria tão longe quanto desactivá-lo usando o interruptor da linha de comando.Em teoria, a teoria e a prática são as mesmas. Na prática, não são.O Java spec diz Esse sistema.o gc sugere chamar a recolha do lixo. Na prática, ele apenas cria um fio e corre imediatamente no Sun JVM. Embora, em teoria, possas estar a estragar uma implementação bem afinada da recolha de lixo da JVM., a menos que esteja a escrever um código genérico destinado a ser implantado em qualquer JVM lá fora, não se preocupe com isso. Se funcionar para ti, fá-lo.
Pode ver o stagemonitor . É um monitor de desempenho de aplicações java (web) de código aberto. Ele captura métricas de tempo de resposta, métricas JVM, solicitar detalhes (incluindo uma pilha de chamadas capturada pelo analista de Pedidos) e muito mais. A sobrecarga é muito baixa.
Opcionalmente, você pode usar a grafite da base de dados great timeseries com ela para armazenar um longo histórico de pontos de dados que você pode olhar com painéis finos. Exemplo:
Olha para isto. a página web do projecto para ver imagens, descrições de funcionalidades e documentação.
Nota: eu sou o desenvolvedor do stagemonitor
Embora não vá perturbar o JVM com chamadas explícitas para eles podem não ter o efeito que espera. Para realmente entender o que está acontecendo com a memória em um JVM com Leia qualquer coisa e tudo o que o [[17]}Brian Goetz escreve.XX:-o PrintGC imprime mensagens na recolha do lixo. Administravel.
-XX:-PrintGCDetails Print more details at garbage collection. Administravel. (Introduzido em 1.4.0.)
-XX:-Impressgctimestamps imprimir datas na recolha do lixo. Fácil de gerir (introduzido em 1.4.0.)
-XX: - PrintTenuringDistribution Imprimir informação sobre a idade.
Sistema de execução explícita.gc () em um sistema de produção é uma idéia terrível. Se a memória chegar a qualquer tamanho, todo o sistema pode congelar enquanto um GC completo está em execução. Em um servidor multi-gigabyte, isso pode ser facilmente muito perceptível, dependendo de como o jvm é configurado, e quanto headroom ele tem, etc etc - eu vi pausas de mais de 30 segundos.
Outra questão é que ao chamar explicitamente o GC não está a monitorizar como o JVM está a gerir o GC, você está realmente alterando - dependendo de como você configurou o JVM, ele vai coletar lixo quando apropriado, e geralmente incrementalmente (ele não apenas executar um GC completo quando ele fica sem memória). O que você vai imprimir não será nada como o que o JVM vai fazer por conta própria - para uma coisa você provavelmente vai ver menos GC automáticos / incrementais como você vai estar limpando a memória manualmente.
Como o post de Nick Holt indica, as opções para imprimir a actividade do GC já existem como JVM. bandeira. Pode ter uma linha que imprime gratuitamente e está disponível a intervalos razoáveis, isto vai mostrar-lhe a verdadeira idade.Se gosta de uma boa maneira de fazer isto a partir da linha de comando use jstat:
Http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html
Dá informações em bruto a intervalos configuráveis, o que é muito útil para fins de registo e grafagem.
Se usar o java 1.5, poderá ver o ManagementFactory.getMemoryMXBean() que lhe dão números em todos os tipos de memória. heap and non-heap, perm-gen.
Um bom exemplo pode ser encontrado lá http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space
Se você usar o JMX desde que o histórico de runs GC você pode usar o mesmo antes/depois dos números, você simplesmente não tem que forçar um GC.
Você só precisa ter em mente que esses GC runs (normalmente um para a antiga e outro para a nova geração) não estão em intervalls regulares, então você precisa extrair a hora de início, bem como para plotar (ou você plotar contra um número de sequência, para propósitos mais práticos que seriam suficientes para plotar).
Por exemplo no Oracle HotSpot VM com ParNewGC, existe um JMX MBean chamado java.lang:type=GarbageCollector,name=PS Scavenge, tem um atributo Lastginfo, devolve um CompositeData da última execução do YG scavenger. É gravado com duration, absoluto startTime e memoryUsageBefore e memoryUsageAfter.
Basta usar um temporizador para ler esse atributo. Sempre que um novo startTime aparece, você sabe que ele descreve um novo evento GC, você extrai a informação de memória e continua pesquisando para a próxima atualização. (Não tenho a certeza se um AttributeChangeNotification de alguma forma pode ser usado.)
Como foi sugerido, tente o VisualVM para obter uma visão básica.
Você também pode usar o Eclipse MAT, para fazer uma análise mais detalhada da memória.
Não faz mal fazer um sistema.gc () desde que você não dependa disso, para a correção do seu programa.O problema com o sistema.gc, é que o JVM já atribui automaticamente tempo ao coletor de lixo com base no uso da memória.
No entanto, se você está, por exemplo, trabalhando em uma condição muito limitada de memória, como um dispositivo móvel, sistema.gc permite que você alocar manualmente mais tempo para esta coleta de lixo, mas ao custo do tempo da cpu (mas, como você disse, Você não está muito preocupado com problemas de desempenho da gc).
As melhores práticas seriam provavelmente para apenas usá-lo onde você pode estar fazendo grandes quantidades de desalocação (como limpar um grande array).
Todos considerados, uma vez que você está simplesmente preocupado com o uso da memória, sinta-se à vontade para chamar gc, ou, melhor ainda, ver se faz muita diferença de memória em seu caso, e depois decidir.
Adicionando à lista de respostas, o JConsole (incluído no directório jdk/bin) é também uma boa interface para experimentar.