Custo desempenho de criação de perfis uma aplicação web em Produção

Question

Eu estou tentando resolver problemas de desempenho com uma grande e complexa aplicação web tomcat java. O maior problema no momento é que, de tempos em tempos, os picos de uso de memória e a aplicação deixa de responder. Eu fixo tudo o que eu posso consertar com profilers de registo e análise Bayesiana dos arquivos de log. Estou considerando a execução de um profiler na produção tomcat do servidor.

Uma nota para o leitor com suaves Sensibilidades:

Eu entendo que alguns podem achar a própria noção de perfilar uma ofensiva aplicativo de produção. Tenha certeza de que eu ter esgotado a maioria das outras opções. A razão que eu estou considerando isso é que eu não tenho os recursos para duplicar completamente a nossa configuração de produção no meu servidor de teste, e eu fui incapaz de fazer com que as falhas de interesse no meu servidor de teste.

Perguntas:

Eu estou procurando respostas que funcionam tanto para uma aplicação java web em execução no tomcat, ou responder a esta pergunta de forma agnóstica linguagem.

• Quais são os custos de criação de perfil de desempenho?
• Quaisquer outras razões pelas quais ele é uma má idéia para se conectar remotamente e perfil de um aplicativo web em produção (modos de falha estranhos, questões de segurança, etc)?
• Quanto custa o perfil de efeito a impressão pé da memória?
• Especificamente estão lá java profiling ferramentas que têm custos muito baixos de desempenho?
• Qualquer java profiling ferramentas projetadas para perfilar aplicações web?
• Alguém tem benchmarks sobre os custos de criação de perfil com VisualVM desempenho?
• O que aplicações de tamanho e conjuntos de dados pode VisualVM escala para?

Answer 1

OProfile e seu ancestral DPCI foram desenvolvidos para perfilar sistemas de produção. A sobrecarga para estes é muito baixo, e eles o perfil de seu sistema completo , incluindo o kernel, assim você pode encontrar problemas de desempenho no VM e no kernel e bibliotecas.

Para responder às suas perguntas:

1. Overhead: Estes são amostrado profilers, ou seja, elas geram temporizador ou interrupções do contador de desempenho em algum intervalo regular, e eles vejam o que o código está sendo executado. Eles usam isso para construir um histograma de onde você gasta o seu tempo, ea sobrecarga é muito baixa (1-8% é o que afirmam ) para intervalos de amostragem razoáveis.

   Dê uma olhada este gráfico de amostragem contra sobrecarga de frequência para OProfile. Você pode sintonizar a frequência de amostragem para menor sobrecarga se os padrões não são do seu agrado.

2. Uso na produção: A única ressalva a usar OProfile é que você precisa instalá-lo em sua máquina de produção. Eu creio que há suporte no kernel do Red Hat desde RHEL3, e eu tenho certeza que outras distribuições apoiá-lo.

3. Memória:. Não tenho a certeza que o consumo de memória exata do OProfile é, mas acredito que ele mantém relativamente pequenos buffers em volta e despeja-los em arquivos de log ocasionalmente

4. Java: OProfile inclui agentes de perfis que suporte Java e que está ciente de código em execução na EIC. Então você vai ser capaz de ver as chamadas Java, não apenas as chamadas C no intérprete e JIT.

5. Web Apps:. OProfile é um perfilador de nível de sistema, portanto, não é consciente de coisas como sessões, transações, etc. que um aplicativo web teria

   Dito isto, é uma full-sistema profiler, por isso, se o seu problema de desempenho é causada por maus interações entre o sistema operacional e o JIT, ou se é de alguma biblioteca de terceiros, você' vai ser capaz de ver isso, porque OProfile perfis do kernel e bibliotecas. Esta é uma vantagem para os sistemas de produção, como você pode detectar os problemas que são devidos a erros de configuração ou particularidades do ambiente de produção que pode não existir em seu ambiente de teste.

6. VisualVM: Não tenho certeza sobre este, como eu não tenho experiência com VisualVM

Aqui está um tutorial sobre o uso OProfile para encontrar gargalos de desempenho .

Answer 2

Eu usei YourKit ao perfil aplicativos em um ambiente de produção de alta carga, e enquanto não foi certamente um impacto, ele foi facilmente um um aceitável. YourKit faz uma grande negócio de ser capaz de fazer isso de uma forma não forma -invasive, tais como transformar seletivamente desligar certas características de perfis que são mais caros (é uma escala móvel, realmente).

O meu favorito aspecto é que você pode executar a máquina virtual com o agente YourKit correr, e tem impacto no desempenho zero. é somente quando você conectar o GUI e começar a perfilar que ele tem um efeito.

Answer 3

Não há nada errado em perfis de aplicativos de produção. Se você trabalha em aplicações distribuídas, há momentos em que uma exceção outofmemory ocorre em um cenário de probabilidade muito original que é muito difícil de reproduzir em um dev / estágio / UAT ambiente.

Você pode tentar usar perfis personalizados, mas se você estiver com pressa e ligar / definição upa profiler em uma caixa de produção vai levar tempo, você também pode usar a JVM para tomar um despejo de memória (JVMs de despejo de memória também lhe dá passe dump)

1. Você pode ativar a geração automática na linha de comandos da JVM, usando a seguinte opção: -XX: + HeapDumpOnOutOfMemoryError

2. ele projeto Eclipse Memória Analyzer tem uma característica muito poderoso chamado “grupo por valor”, o que torna possível a construção de uma consulta de objeto e reagrupar as instâncias por um valor de campo. Isto é útil no caso em que você tem um monte de instâncias que são contendo um conjunto menor de valores possíveis, e você pode ver que os valores estão sendo usados ??mais. Isto realmente me ajudou a entender um pouco de memória complexo despeja então eu recomendo que você experimentá-lo.

Answer 4

Você também pode considerar o uso de uma das modernas HotSpot JVM - Java Flight Recorder e Java Mission Control . É um conjunto de ferramentas que permitem a você informações de tempo de execução de baixo nível de coleta com a sobrecarga da CPU cerca de 5% (eu não posso provar a última declaração de qualquer forma, esta é a declaração do coordenador do Oracle que apresentou o recurso e demonstração ao vivo).

Você pode usar essa ferramenta, desde que a sua aplicação está em execução 1_7u40 JVM ou superior. Para permitir a recolha informações de tempo de execução, você precisa começar a JVM com bandeiras particulares:

Por padrão, JFR está desativado no JVM. Para habilitar JFR, você deve lançar seu aplicativo Java com o -XX: + FlightRecorder opção. Porque JFR é uma característica comercial, disponível apenas nos pacotes comerciais baseados em Java Platform, Standard Edition (Oracle Java SE Avançado e Oracle Java SE Suite), você também tem que habilitar recursos comerciais usando os XX: UnlockCommercialFeatures + opções.

(Citado http: // docs. oracle.com/javase/8/docs/technotes/guides/jfr/about.html#sthref7 )

Eu adicionei esta resposta como esta é opção viável para perfilar na produção IMO.

Também há um Eclipse plug-in que os suportes JFR e do JMC e capaz de exibir user-friendly informações.

Answer 5

As ferramentas têm melhorado muito ao longo dos anos. Estes dias, a maioria das pessoas que têm necessidades como estes usar uma ferramenta que ganchos para API de instrumentação de Java em vez da API de perfis. Certamente há mais exemplos, mas NewRelic e AppDynamics vêm à mente. As soluções à base de instrumentação normalmente executado como um agente na JVM e constantemente dados de recolha. Eles relatam os dados a um nível superior (transação de negócios, transações web, transação de banco de dados) do que a abordagem de perfis de idade e permitir que você cavar mais fundo (para baixo para o método ou linha), se necessário. Você pode até mesmo configurar o monitoramento e alertas, para que possa acompanhar / alerta em métricas como tempo de carregamento de página e desempenho em relação aos SLAs. Com estes grandes ferramentas, você realmente deve ter nenhuma razão para executar um profiler na produção por mais tempo. O custo de funcionamento deles é insignificante.