Ajuste de desempenho do IBM WebSphere e IBM Tivoli Monitoring

Melhores práticas para uma infraestrutura de POWER7 WebSphere Application Server 7

Descubra as melhores práticas e ferramentas para criar melhoria contínua de tempos de resposta de transações, bem como avaliações de desempenho iniciais para aquisição de hardware para arquiteturas IBM WebSphere Application Server 7 e POWER7 com o IBM Tivoli Monitoring.

Jason Petersson, Systems Planning Engineer, Visa

Jason Peterssonason Meiers é engenheiro de planejamento de sistemas para a VISA no Vale do Silício, Califórnia, e trabalha em uma infraestrutura IBM WebSphere 7, IBM Tivoli 7 e Power 7. Ele é autor de um IBM RedBook e vários artigos técnicos. Jason é formado em Sistemas da Informação pela Fachhochschule Karlsruhe na Alemanha e é certificado da IBM em WebSphere 7.



13/Jan/2011

Mais transações por segundo (TPS) requerem ajuste de tempos de resposta, bem como menor utilização de CPU para transações financeiras e com base na Web. TPS afeta diretamente os tempos de resposta ao usuário e o custo de sua infraestrutura de hardware. Este artigo mostra como ajustar o IBM WebSphere Application Server 7 no hardware IBM POWER7® para obter melhor desempenho.

Topologias de arquitetura

O serviço de preparação de hambúrguer, mostrado na Figura 1 descreve a configuração do perfil IBM POWER de POWER7 LPARs para a alocação de recursos. Cada LPAR controlador de pedidos tem quatro processadores físicos (oito CPUs lógicas) com 8GB de RAM para processar a carga de trabalho recebida. Outros serviços—por exemplo, o perfil de serviço de cebola—estão configurados com dois processadores físicos (quatro CPUs lógicas) e 8GB de RAM. O fato de certos serviços terem mais processadores é determinado pelos requisitos de carga daquele serviço específico. Neste caso, o serviço controlador de pedidos é chamado para cada pedido, enquanto que os serviços de queijo e de cebola não o são.

Acrônimos usados frequentemente

  • E/S: Entrada/Saída
  • JDK: Java software development kit
  • LPAR: Partição lógica
  • SOA: Arquitetura Orientada a Serviços
  • XML: Linguagem de marcação extensível

A camada de aplicativos se refere à camada interna que inclui um serviço controlador de pedidos para processar transações com base em serviços, bem como uma lista de outros serviços Apache Tuscany (Open SCA) com base no WebSphere Application Server versão 7. Nesse exemplo, o aplicativo cria um hambúrguer. Com base nos pedidos dos clientes, serviços específicos são executados (por exemplo, serviço de grelhagem do hambúrguer, serviço de alface, serviço de cebola, serviço de embalagem, serviço de tomate e serviço de queijo).

Figura 1. O serviço de hambúrguer
O serviço de hambúrguer

Topologias para monitoramento e gerenciamento de sistemas incluem o IBM Tivoli Monitoring, em que os dados do monitoramento são consolidados para oferecer visualizações e gerenciamento de desempenho. A topologia do Tivoli inclui o IBM Tivoli Enterprise Monitoring Server como o hub primário para o monitoramento de todos os sistemas, um Tivoli Enterprise Monitoring Server de backup, caso o primário falhe, o IBM Tivoli Enterprise Portal Server e o número de servidores remotos a tratar, bem como o balanceamento de carga do número de agentes de monitoramento de sistemas.

A Figura 2 mostra a configuração de cada instância dentro de uma POWER7 LPAR com um processador físico (duas CPUs lógicas) e 4GB de RAM. Essa configuração cobre infraestruturas de até 500 servidores para a coleta de dados de monitoramento de sistemas.

Figura 2. A arquitetura do Tivoli Monitoring versão 6.2
A arquitetura do Tivoli Monitoring versão 6.2

A Figura 3 mostra o diagrama da topologia do IBM Tivoli Composite Application Manager para Application Diagnostics versão 7.1 para a coleta de dados de desempenho de aplicativos e ferramentas de diagnóstico para realizar ajuste de desempenho. A distribuição gerada por LPAR do Tivoli Composite Application Manager serve ao mecanismo de visualização, kernel, serviços de publicação, servidor global de publicação, despachante de mensagens, agente de archive. O servidor de publicação fornece escalabilidade e disponibilidade para criação de perfis de aplicativos distribuídos.

Figura 3. Arquitetura do Tivoli Composite Application Manager versão 7.1
Arquitetura do Tivoli Composite Application Manager versão 7.1

Requisitos

Requisitos de desempenho para tempos de resposta de transações (ou seja, TPS) incluem o tempo de resposta mediano (150ms), o tempo de resposta médio (170ms), o percentil 95% do tempo de resposta (180ms) e a utilização de CPU a 20-35% em um único núcleo POWER7.

Escalabilidade

A escala vertical é implementada adicionando várias instâncias da Java™ Virtual Machine (JVM) em uma única LPAR aproveitando o mesmo processador e a memória. É possível aproveitar essa arquitetura ao ajustar seu aplicativo para tal nível de serialização de forma que a execução de várias JVMs possa aumentar sua carga de trabalho. Use essa configuração, se processadores LPAR e memória ainda estiverem disponíveis.

A escala horizontal é implementada usando várias LPARs, cada uma com uma das várias instâncias do WebSphere Application Server a partir dos mesmos clusters de serviço ou aplicativo. (Esta configuração é mais bem usada para serviços que consomem muito processador e memória.) Na Figura 1, o controlador de pedidos chamado para cada pedido de serviço é um exemplo de escala horizontal, pois os padrões do controlador parecem usar muito processador e a memória é determinada pela carga útil de cada pedido de serviço.


Melhores práticas de uso e gerenciamento de desempenho

Esta seção descreve ferramentas que podem ser usadas para determinar onde estão localizados os gargalos de desempenho na transação.

Determinação de problemas

O Tivoli Composite Application Manager fornece muitas ferramentas e gráficos para monitorar sua infraestrutura:

  • Gráfico de utilização de CPU da JVM: Este gráfico do Tivoli Composite Application Manager (consulte a Figura 4) fornece métricas de utilização de uma única JVM, em vez de, simplesmente, utilização de CPU do sistema. Neste caso, pode-se ver que, para este aplicativo, há uma utilização mínima de processador específica da JVM—entre 10 e 25%.
    Figura 4. Utilização de CPU da JVM (Percentual, última hora)
    Utilização de CPU da JVM (Percentual, última hora)
  • Gráfico de utilização de memória da JVM: Este gráfico do Tivoli Composite Application Manager (consulte a Figura 5) fornece insights sobre a utilização de uma única JVM, em vez de, simplesmente, utilização de memória do sistema. Mas, neste caso, pode-se ver que há um saldo de 30% em utilização de memória quando a carga é gerada para o aplicativo.
    Figura 5. Utilização de memória da JVM (Percentual, última hora)
    Utilização de memória da JVM (Percentual, última hora)
  • Rendimento em nível do aplicativo: O rendimento de um pedido está disponível no Tivoli Composite Application Manager para determinação de disponibilidade, bem como de problemas (consulte a Figura 6.). Frequentemente, sem rendimento e utilização, gargalos de desempenho lado a lado são difíceis de serem correlacionados com rendimento, tempos de resposta de transação e utilização de CPU ou memória. Para esse aplicativo, há uma média de 240 transações processadas por minuto—cerca de 4 TPSs.
    Figura 6. Rendimento (pedidos/min, última hora)
    Rendimento (pedidos/min, última hora)
  • Tempos de resposta: Tempos de resposta são indicadores críticos de desempenho, tanto para seu negócio quanto para seus clientes. Neste caso, o Tivoli Composite Application Manager mostra transações iniciais com tempos de resposta extremamente altos, no intervalo de 12 segundos (consulte a Figura 7). Uma vez que todos os recursos tenham sido carregados, os tempos de resposta melhoram para níveis inferiores a um segundo—cerca de algumas centenas de milissegundos.
    Figura 7. Tempo de resposta (segundos/min, última hora)
    Tempo de resposta (segundos/min, última hora)
  • Conjunto de encadeamentos do contêiner de Web: Este conjunto de encadeamentos é inicialmente definido para o mínimo de 50 e o máximo de 50. Na maioria dos casos, essa configuração é suficiente. Para esse exemplo, 10 pedidos simultâneos foram enviados; portanto, 12 encadeamentos de contêiner da Web foram usados. Como mostra a Figura 8 , há um máximo de 50 encadeamentos e 24% são realmente consumidos.
    Figura 8. Conjuntos de encadeamentos
    Conjuntos de encadeamentos

    Por padrão, no WebSphere Application Server o despacho assíncrono de pedidos da Web não está ativado. Ative essa configuração para processar pedidos da Web assíncronos clicando em AppServers > Server > Web container > Asynchronous Request Dispatching. A seguir, em Configuration , selecione Allow Asynchronous Request Dispatching.

    Em perfis de infraestrutura em cluster, faz sentido monitorar encadeamentos de Distribution & Consistency Services (DCS) (consulte a Figura 9). Os encadeamentos DCS indicam conexões de rede entre cada membro de um cluster, incluindo a sincronização de atualizações de configuração. Para configurações de produção, a IBM recomenda desativar DCS no console integrado do WebSphere, pois este recurso só é necessário durante a configuração.

    Figura 9. Encadeamentos TCP DCS
    Encadeamentos TCP DCS
  • Taxa de falha de transações: A taxa de falha de transações (consulte a Figura 10) ajuda a identificar rapidamente, ao ajustar o desempenho, se as transações estão apresentando falha. Tais falhas podem ocorrer, por exemplo, se um banco de dados ou outro serviço que a transação requer estiver indisponível. Neste exemplo de desempenho de carga pequena, nenhuma transação está falhando, o que indica que todas as métricas obtidas são válidas para captura em uma comparação de ajuste.
    Figura 10. Taxa de falha de transações
    Taxa de falha de transações
  • Conjuntos de conexão com o banco de dados: No Tivoli Composite Application Manager, o uso de conjuntos de conexões com o banco de dados (consulte a Figura 11) ajuda a determinar o uso e se os limites para o banco de dados são empregados. Se a transação não puder acessar a origem de dados ou o encadeamento do pedido precisar aguardar a disponibilidade do banco de dados, isso poderá afetar diretamente os tempos de resposta e o rendimento.
    Figura 11. Conjuntos de conexões com o banco de dados
    Conjuntos de conexões com o banco de dados

    O agente que o Tivoli Monitoring fornece para monitoramento em nível de sistema inclui atividade de rede para ajudar a determinar, com base em testes de carga de desempenho, a quantidade de dados que está passando pela rede (consulte a Figura 12). No caso deste exemplo, a taxa de pacotes agregados por segundo é de 50. Esse valor pode ser aumentado com base na carga útil (pedido e resposta XML) dos aplicativos e serviços.

    Figura 12. Atividade de rede
    Atividade de rede

    Outras métricas incluem médias de carga de CPU, que podem incluir tempo inativo. Neste caso, os totais acima de 15 minutos têm como média 100%. Também são fornecidas porcentagens de CPU para usuário, CPU de sistema e espera de E/S. No intervalo de captura do Tivoli Monitoring, pode-se ver o tempo inativo de 100% na Figura 13. Os agentes de monitoramento de sistema do Tivoli Monitoring também fornecem análise de tendência para ajudar a tomar melhores decisões no decorrer do tempo.

    Figura 13. Utilização de CPU do Tivoli Monitoring
    Utilização de CPU do Tivoli Monitoring
  • O analisador nmon :Em certos casos, a utilização de CPU para ajuste de desempenho poderá exigir mais dados em tempo real para o ajuste de aplicativos e serviços em execução no WebSphere Application Server. O analisador nmon , uma ferramenta freeware da IBM, fornece esses dados em tempo real. Neste exemplo, a POWER7 LPAR foi configurada para dois processadores físicos (quatro CPUs lógicas) exibidos no nmon como quatro processadores (consulte a Figura 14). Cada CPU lógica e sua utilização são mostradas e a média total é de 50%. Tenha em mente que a medição de utilização de CPU é obtida em intervalos com base no tempo e nunca é exata. Portanto, assegure-se de usar várias ferramentas e modos.
    Figura 14. Utilização de CPU no nmon
    Utilização de CPU no nmon

    A utilização de CPU no nmon também fornece uma opção l para obter a média total em um período maior de tempo ao capturar métricas de CPU. Neste exemplo, há 90% de utilização de CPU com utilização recorrente de 0%. Esse resultado é baseado na ferramenta de desempenho de carga de cliente enviando 10 pedidos simultâneos e aguardando encadeamentos bloqueados. É possível ver isso na Figura 15, bem como em um arquivo JavaCore e em uma sugestão dos encadeamentos de contêiner da Web monitorados pelo Tivoli Composite Application Manager.

    Figura 15. Utilização de CPU no nmon com a opção l
    Utilização de CPU no nmon com a opção l
  • top, topas e prstat. Na maioria dos sistemas UNIX® e Linux® , top, topasou prstat estão disponíveis para exibir utilização, incluindo memória e CPU. No exemplo da Figura 16,a opção H é definida para exibir utilização em nível de encadeamento. Cada encadeamento de usuário was é um encadeamento dentro do WebSphere Application Server e, em alguns casos, consome 14% da CPU. Esse consumo pode ser resultado de vários pontos: o pedido de serviço de fato, processando um encadeamento de contêiner; encadeamentos DCS sincronizando com outros membros de um cluster; ou outros encadeamentos específicos do WebSphere Application Server.
    Figura 16. Utilização de CPU em top
    Utilização de CPU em top
  • vmstat. No vmstat, é possível ver utilização, bem como outras métricas, para determinar gargalos em nível de sistema causados pelo aplicativo. As colunas típicas de CPU us, sys, id e wa aparecem nas outras ferramentas mencionadas anteriormente.

    Se estiver trabalhando com vmstat no Red Hat Linux em execução no POWER7, você também obterá as informações de steal na coluna mais à direita. Essa métrica indica a utilização de CPU de que o sistema faz uso, em vez da utilização de CPU de usuários. No exemplo mostrado na Figura 17, apesar da carga de desempenho estar em execução, é possível ver um alto nível de steal e somente 18–21% de utilização de CPU de usuários para o WebSphere Application Server. Esse resultado pode indicar que um perfil de configuração de LPAR com duas CPUs físicas é alto demais para esse aplicativo sendo executado em uma única JVM por causa da troca de contextos e processamento de métodos específicos que não são do WebSphere Application Server.

    Figura 17. Utilização de CPU no vmstat
    Utilização de CPU no vmstat

    Os dados do processador na coluna r indicam o número de encadeamentos aguardando para serem processados. Um número alto indica um gargalo de encadeamentos e muitos encadeamentos em espera. Como a carga só executou de forma breve, mostrado nas primeiras quatro linhas, não houve encadeamentos em espera.

Carga

Gerar carga é crítico para o ajuste bem-sucedido de um aplicativo. É preciso estabelecer uma linha de base antes de cada alteração de ajuste com uma ferramenta de carga. A Figura 18 mostra o Jmeter sendo usado para gerar carga do WebSphere Application Server. Para iniciar a carga, os requisitos do Jmeter são:

  • Uma URL de serviço da Web
  • Uma carga útil de pedido XML
  • O número de usuários simultâneos
Figura 18. Teste de carga no Jmeter
Teste de carga no Jmeter

Para a geração da carga de desempenho—e especialmente para um pedido único que requer a carga útil de resposta—a Figura 19 mostra soapUI. Em alguns casos, talvez você queira simplesmente confirmar que a transação foi bem-sucedida e validar a carga útil de resposta. Nesse exemplo, pode-se ver os altos tempos de resposta no início das transações do aplicativo—o resultado da carga das classes, origens de dados e cache iniciais. Antes de executar altos volumes de usuários simultâneos, poderá ser útil iniciar algumas transações de encadeamento único e visualizar a carga útil antes de executar a carga com relação ao novo parâmetro de ajuste de mudança na configuração.

Figura 19. Teste de serviço no soapUI
Teste de serviço no soapUI

Diagnóstico

Depurar problemas em um ambiente de desenvolvimento pode ser rápido e eficiente para um único aplicativo, mas solucionar problemas em um aplicativo com vários serviços pode ser desafiador. O Tivoli Composite Application Manager for Application Diagnostics correlaciona transações da Java 2 Platform, Enterprise Edition (J2EE) com J2EE e/ou J2EE com WebSphere MQ abrangendo várias LPARs. Isso ajuda a identificar o fluxo da transação e fornece insights sobre o código para determinar tempos de resposta no nível de método. Como mostra a Figura 20 , o relatório de rastreio do Tivoli Composite Application Manager for Application Diagnostics identificou métodos no código do aplicativo com tempos de resposta altos. Os métodos 3, 7, 12 e 13 foram marcados com tempos de resposta em milissegundos de dois, e até mesmo três dígitos. Além disso, é possível detalhar cada método para encontrar uma pane adicional, se desejar saber qual a seção do código que precisa de correção.

Figura 20. O detalhamento de uma transação no Tivoli Composite Application Manager
O detalhamento de uma transação no Tivoli Composite Application Manager

Caminhos de execução da transação também estão disponíveis com o Jinsight para identificar a causa de altos tempos de resposta. O tempo de CPU decorrido de cada método é determinado, identificando rapidamente qual código é responsável pelos problemas de execução (consulte a Figura 21).

Figura 21. Criação de perfil de métodos do Xtrace
Criação de perfil de métodos do Xtrace

Essa figura mostra o padrão de execução do servlet HamburgerService e quais métodos estão causando altos tempos de resposta. Para capturar uma única transação do Jinsight, comece implementando o Jinsight. Para tal, adicione o arquivo libjinsight-pLinux.so ao caminho de classe do WebSphere:

JVM Arguments
 -agentlib:jinsight-pLinux=localFileName=/tmp/trace.trc,localID=10
Start Jinsight Trace
jinctl start 10
Stop Jinsight Trace
jinctl stop 10

Uma vez que um método tenha sido identificado com altos tempos de resposta e antes de enviar um pedido para um aplicativo ou correção de serviço, execute o Xtrace para aquele método para determinar se ele é realmente o problema. O benefício de executar o Xtrace é que ele permite criar o perfil de um único método, em vez do aplicativo ou serviço completo. Portanto, é possível executar carga com relação a um serviço e determinar tempos de resposta mais precisos, incluindo os tempos de resposta de um único método que tenha sido identificado como suspeito de causar os altos tempos de resposta.

Para implementar o Xtrace no WebSphere Application Server 7, adicione a seguinte linha nos argumentos da JVM e reinicie o servidor de aplicativos para incluir a alteração:

-Xtrace:methods={com/ibmtools/*},print=mt

Quando tiver definido os métodos no Xtrace, você verá no arquivo native_err.out cada chamada de entrada de método marcada com > e cada saída de método marcada com <. Os parâmetros e atributos do método são marcados com -, apesar de isso não oferecer tanto valor quanto os tempos de execução dos métodos de entrada e saída.

A política de coleta de lixo do Java determina o desempenho de seu aplicativo e, por padrão, é definida como optthruput. Esta configuração gera e mantém todos os objetos em um único contêiner de heap e, portanto, tem ciclos de coleta de lixo que impactam no desempenho. Para melhorar o desempenho em todos os aplicativos, use a configuração condicional de geração gencon do IBM JDK para a coleta de lixo:

-Xgcpolicy:gencon -Xmnx124M -Xmns124M  -Xmos900M

Como a política de coleta de lixo condicional de geração divide o heap em duas seções, poderá ser útil especificar os tamanhos dessas seções do heap. Uma seção é chamada de nursery e contém objetos que deixarão o heap na próxima coleta ou ciclo global de coleta de lixo. A outra seção é chamada tenured e contém objetos que deixarão o heap somente depois de coletas de lixo globais.

A nursery é especificada no aplicativo de amostra e pode-se ver, no arquivo native_err.out, as respostas da coleta de lixo. Na linha 1 da Figura 22, intervalms é 13072,241 ms, o que é excepcional e poderia ser uma preocupação para a coleta de lixo de nursery. Em cenários de alto volume com intervalos mais curtos (por exemplo, entre 50 e 100ms), a alta utilização de CPU para coletas de lixo é uma preocupação. Ajustar o desempenho dos tamanhos das seções de nursery e tenured do heap é obrigatório.

Figura 22. Saída de um dump do encadeamento
Saída de um dump do encadeamento

Arquivos principais indicam onde encadeamentos estão bloqueados ou aguardando e servem como o ponto inicial da investigação de desempenho. No Tivoli Composite Application Manager e no Linux ou UNIX, kill -3 <pid> gera esse arquivo para investigação. O uso do Tivoli Composite Application Manager como uma ferramenta de gerenciamento de desempenho centralizada para o JavaCore é útil, pois não são necessárias conexões remotas adicionais ou cópias dos arquivos em toda a infraestrutura.


Resumo

Neste artigo, você aprendeu sobre o ajuste de uma implementação de WebSphere Application Server 7 e POWER7 executando serviços Open SCA. Com base na lista de métodos e ferramentas fornecida aqui, é possível desenvolver um processo para melhorar tempos de resposta, utilização de CPU e custo de hardware. Transações financeiras e pedidos com base na Web melhoram ainda mais com recursos e serviços SOA adicionados.

Recursos

Aprender

  • Descubra as melhores práticas de desempenho de SOA para software e hardware IBM.
  • Para obter demos práticas em muitos tópicos relacionados ao WebSphere e visualização em IBM Power Systems®, confira ibmtools.com (veja o filme 41).
  • Technology Store: Navegue pelos DVDs de laboratórios de tecnologia sobre este e outros tópicos técnicos.

Discutir

  • Siga as atualizações de desempenho para o WebSphere, Tivoli e Power no Twitter.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tivoli, WebSphere
ArticleID=608156
ArticleTitle=Ajuste de desempenho do IBM WebSphere e IBM Tivoli Monitoring
publish-date=01132011