Alto uso da CPU - sintomas passando de um servidor para outro depois de saltar

Question

Primeiramente, peço desculpas se não incluí as informações suficientes para solucionar o problema adequadamente. Esse tipo de coisa não é minha especialidade, então é um processo de aprendizado. Se houver algo que eu precise fornecer, por favor me avise e ficarei feliz em fazer o que puder. As imagens associadas à minha pergunta estão no final desta postagem.

Estamos lidando com um ambiente em cluster de quatro servidores de aplicativos Java do WebLogic 9.2. O cluster utiliza um algoritmo de carga round-robin. Outros detalhes incluem:

• Ambiente de tempo de execução Java (TM) 2, Standard Edition (build 1.5.0_12-b04)
• BEA JRockit (R) (compilação R27.4.0-90_CR352234-91983-1.5.0_12-20071115-1605-linux-x86_64, modo compilado)

Basicamente, comecei a observar o desempenho dos servidores, porque nossos clientes estão vendo muito atraso em vários horários do dia. Nossos servidores devem lidar facilmente com as cargas que recebem, por isso não está claro o que está acontecendo. Usando o HP Performance Manager, gerei alguns gráficos que indicam que o uso da CPU está completamente fora de sintonia. Parece que, a qualquer momento, um ou mais dos servidores tem uma utilização de CPU de mais de 50%. Eu sei que isso não é particularmente alto, mas eu diria que é uma bandeira vermelha baseada na utilização da CPU dos outros servidores no cluster WebLogic.

Coisas interessantes para observar:

• A alta utilização da CPU estava ocorrendo apenas no server02 por várias semanas. O servidor travou (extremamente raro; não temos certeza se está relacionado a isso) e ao iniciar o backup, a utilização da CPU foi normal em todos os quatro servidores.
• Reiniciamos todos os quatro servidores gerenciados e o servidor de aplicativos (no server01) ontem, em 28/2. Como você pode ver, server03 e server04 escolheram o comportamento que foi visto no server02 antes.
• A utilização da CPU é um processo Java de propriedade do usuário do aplicativo (appown).
• O número de transações é consistente em todos os servidores. Não parece que qualquer servidor esteja lidando com mais do que outro.

Se alguém tiver alguma ideia ou puder pelo menos me indicar a direção certa, isso seria ótimo. Mais uma vez, por favor, deixe-me saber se há alguma informação adicional que eu deveria postar. Obrigado!

    

Answer 1

O balanceamento de carga é totalmente robusto ou está fazendo aderência com base em IP ou cookie? Você poderia ter algum tipo de tráfego de usuário que adere a um servidor e se move após a reinicialização - especialmente se outro dos seus servidores estiver chamando um aplicativo no cluster. Então cruze-o contra ocorrências reais no servidor.

Você também pode ter uma condição de corrida no aplicativo que determinadas operações obtenham em um loop. Para isso, você poderia pegar um thread dump (kill -3 pid) e retirá-lo do seu log stdout e executar algo como Samurai nele para ver o que acontece.

Também gostaria de ativar o registro da coleta de lixo e ver se os horários de GC estão correlacionados com os tempos de atraso percebidos.

    

Answer 2

Não sou especialista em cluster ou Bea, mas em problemas de análise de desempenho não há apenas CPU. Quais são os dados sobre memória, disco e rede? As ferramentas para obtenção de dados são top (cpu e memória, com muitos detalhes e também por processo), vmstat (memória, cpu, disco), sar (pacote sysstat no linux, com todos os dados possíveis e registros históricos). Então, qual é o sistema operacional de tais máquinas e em qual versão?

    

Answer 3

Eu gostaria de instalar um probe e perfil Java no aplicativo da Web para investigar onde é exatamente esse 50% do processador.

    

Answer 4

Acione um dump de thread ou dois em cada um dos servidores. Você provavelmente encontrará um dos servidores com um encadeamento em execução que não está sendo executado nos outros servidores. Verifique também a utilização da memória através do console. Eu vi o WebLogic entrar em um loop de coleta de lixo quando não há memória suficiente.