Aproveitando grandes números de processadores no WebSphere Portal para Solaris

Opções de documento Opções de documento que necessitam de JavaScript não são exibidas Discutir Classificar esta página Ajude-nos a melhorar este conteúdo

Nível: Intermediário

Martin Presler-Marshall, Performance Analyst, IBM
Laura Yen, Performance Analyst, IBM
Daniel Edwin, Software Engineer, Sun Microsystems Inc.

21/Jul/2009

O IBM® WebSphere® Portal pode ser executado em vários sistemas com arquiteturas totalmente diferentes. Arquiteturas com um grande número de processadores podem ser um desafio: como obter bom desempenho nesses sistemas? Este artigo descreve a experiência da equipe de desempenho do WebSphere Portal, mostrando como configuramos o sistema para usar bem os recursos disponíveis. Ele é voltado para administradores ou arquitetos de sistema experientes, no caso de implementações de WebSphere Portal em um ambiente Sun Solaris embora as lições básicas do artigo também se apliquem a outras plataformas.

Nota do editor: Conhece muito esse tópico? Deseja compartilhar seu conhecimento? Participe hoje do programa wiki de software IBM Lotus.

Introdução

Os sistemas modernos de servidor avançaram muito em relação aos sistemas de soquete único e soquete duplo do passado. Hoje em dia, a maioria dos servidores usados em aplicativos comerciais tem um ou mais processadores multinúcleo. O multiencadeamento de hardware, como hyperthreading ou multiencadeamento simultâneo, torna o ambiente mais complexo, acrescentando mais encadeamentos de hardware. Embora o multiencadeamento de hardware já seja usado há muitos anos, agora há sistemas disponíveis que levam essa capacidade para um novo nível, combinando muitos núcleos com alto nível de multiencadeamento de hardware para permitir executar centenas de encadeamentos simultâneos de computação. Um exemplo disso é o servidor Sun CoolThreads, que usa os processadores UltraSPARC T1, T2 e T2 Plus para dar suporte a até 256 encadeamentos simultâneos de computação.

Esse desenvolvimento traz uma questão importante: Quando se trata de sistemas com centenas de encadeamentos simultâneos de computação, o software consegue usar plenamente esse hardware? Examinamos essa questão usando o WebSphere Portal V6.1 executado em um sistema Sun T5240 com 16 núcleos de processador, com suporte a 128 encadeamentos simultâneos de computação. Tentamos diversas abordagens nesse ambiente antes de encontrar uma que resultou em boa utilização do sistema. Este artigo trata das abordagens tentadas, dos resultados das medições dessas configurações, além do ajuste e da configuração usados para obter nossos resultados.

Voltar para parte superior

Descrição da medição

Este cenário é fornecido como modelo de portal em um ambiente de intranet corporativa. Em um ambiente desses, esperamos que os usuários estejam designados a grupos, talvez de acordo com a função de trabalho ou com base em limites organizacionais. Parte do conteúdo desse portal, por exemplo, lugares, páginas e aplicativos, só está disponível a grupos específicos, enquanto outra parte do conteúdo está disponível a todos os usuários autenticados. Apenas um pequeno número de páginas está disponível a usuários não autenticados. Nesse cenário, a maioria dos usuários efetua login no site.

O conteúdo desse cenário é fornecido por alguns portlets simples criados especificamente para esse cenário. O conjunto de portlets desenvolvidos para essas medições usa o API definido no Java™ Portlet Specification 1.0. Nenhum dos portlets usa banco de dados, fonte de conteúdo de rede ou outro sistema externo; em vez disso, esses portlets geram todo o seu conteúdo a partir de entradas codificadas permanentemente.

As interações com o usuário são simuladas por meio de um script de usuário virtual. Cada iteração desse script simula um único usuário interagindo com o site e consiste em múltiplas visualizações de página. Um usuário virtual executa muitas iterações do script durante uma medição. Cada visualização de página no script é considerada uma única transação. Medimos os tempos de resposta de cada transação e a taxa de transação total.

O objetivo da medição é encontrar a mais alta capacidade do sistema, que é definida como a mais alta taxa de transação na qual os tempos de resposta ainda atendem aos nossos critérios.

Ambiente de medição

No nosso ambiente de medição, usamos um servidor de banco de dados separado, um servidor de diretório, um servidor HTTP e o servidor Gerenciador de Implementação. Todos esses servidores são em adição ao sistema principal que está sendo testado, o servidor de aplicativos. São esses os servidores mostrados na figura 1.

Configurações de medição

Tentamos três configurações no nosso ambiente de laboratório. Além disso, há uma quarta configuração que pode fazer sentido nesse ambiente:

• Servidor de aplicativos independente. A implementação mais simples é a do WebSphere Portal em uma única Java virtual machine (JVM) no nó de servidor de portal.
• Ambiente em cluster vertical. O cluster vertical usa os recursos de armazenamento em cluster do IBM WebSphere Application Server para implementar múltiplas Java virtual machines, todas executadas no WebSphere Portal, em um único sistema.
• Ambiente em cluster vertical com conjuntos de processadores. Essa configuração pega a configuração de cluster vertical do item anterior e liga cada processador a um subconjunto de encadeamentos de computação disponíveis.
• A virtualização Solaris usa zonas para fornecer um cluster horizontal. Não incluímos essa configuração em nossas medições de laboratório, mas ela fornece um modo adicional de separar cada JVM de servidor de aplicativos de outros que estejam sendo executados no mesmo servidor físico.

Resultados e observações de medição

Nessas medições, calculamos a capacidade relativa dessas três configurações. Usamos a configuração de capacidade mais baixa e o servidor de aplicativos independente como nosso ponto de linha de base e depois comparamos a capacidade de outras duas configurações com essa linha de base. Essa comparação, mostrada na figura 2, facilita ver a melhoria de capacidade apresentada por essas configurações.

Definimos a capacidade como o nível de carga mais alto no qual todas as transações forneceram tempos de resposta aceitáveis. Assim, o sistema muitas vezes alcança a capacidade antes de o processador ser plenamente utilizado. Observamos as cargas do processador no sistema de portal nas medições mostradas na figura 3.

Fizemos as seguintes observações nas configurações alvo:

• Servidor de aplicativos independente. Infelizmente, uma única JVM não foi capaz de usar plenamente o grande número de encadeamentos de computação, de modo que essa configuração teve a capacidade mais baixa. Como mostra a figura 3, só 21 por cento do sistema estava ocupado quando alcançamos a capacidade máxima. Esse percentual significa que, em média 12 dos 16 núcleos do processador estavam ociosos.
  
  

  O servidor de aplicativos independente é limitado por várias razões:

  • O servidor de aplicativos usa apenas 50 encadeamentos de contêiner de Web para processar todos os pedidos recebidos, de modo que, no máximo, 50 dos 128 encadeamentos de computação podem estar ativos processando pedidos do cliente. Essa limitação evita que o servidor de aplicativos independente use totalmente os recursos de processamento desse sistema. O número de encadeamentos de contêiner de Web pode ser aumentado, mas fazer isso amplia o problema seguinte.
  • Com um grande número de encadeamentos de contêiner de Web ocupados, qualquer contenção de bloqueio dentro do servidor de aplicativos torna-se um gargalo de desempenho, aumentando o tempo de resposta e reduzindo a capacidade.
• Ambiente em cluster vertical. Com várias JVMs em execução simultânea, um ambiente em cluster vertical tem capacidade muito melhor de usar plenamente o sistema. Entre múltiplas JVMs, há mais encadeamentos de contêiner de Web disponíveis, de modo que mais recursos de computação estão disponíveis. Além disso, não há problemas de bloqueio entre diferentes JVMs, de modo que a contenção de bloqueio torna-se um problema menor; cada bloqueio tem um escopo menor. Juntos, esses fatores resultaram em um aumento significativo de capacidade.
• Ambiente em cluster vertical com conjuntos de processadores. Ligando cada JVM a um subconjunto de encadeamentos de computação, limitamos a quantidade de tráfego simultâneo que cada uma pode processar. Embora essa limitação possa parecer causar uma redução de desempenho, o resultado é o oposto: Cada JVM é capaz de processar seu trabalho de modo mais eficiente, fornecendo maior capacidade total. O resultado foi maior capacidade com menor utilização de processador.
• A virtualização Solaris usa zonas para fornecer um cluster horizontal. Embora não tenhamos medido essa configuração, acreditamos que seria bastante adequada para esse aplicativo. A tecnologia de zonas Solaris é usada para virtualizar serviços do sistema operacional e fornece um ambiente isolado e seguro para aplicativos em execução. Uma zona é um ambiente virtualizado de sistema operacional dentro de uma instância do sistema operacional Solaris. Cada zona é isolada das outras, de modo que os processos em uma zona não podem monitorar ou afetar outros processos em outra zonas, mesmo que tenham credenciais de superusuário. Assim, uma zona Solaris é um ambiente leve e seguro de virtualização, em comprometimento do desempenho. Essa abordagem torna uma zona Solaris uma tecnologia ideal de virtualização para um cluster horizontal. As etapas detalhadas para configurar, instalar e implementar zonas no Solaris podem ser encontradas no Guia de Administração do Sistema: Gerenciamento de Recurso de Contêineres Solaris e Zonas Solaris em http://docs.sun.com.

Voltar para parte superior

Usando conjuntos de recursos no Solaris

Os conjuntos de recursos do Solaris permitem agrupar vários processadores em um conjunto e ligar este com um processo Java. Usamos conjuntos de processadores para particionar processadores virtuais.

Em nossos experimentos, descobrimos que o uso mais eficiente para nosso cenário era ligar 21 encadeamentos de computação a uma JVM. Criamos um cluster vertical com seis membros do WebSphere Portal e depois ligamos cada membro a um conjunto de processadores Solaris. O número "certo" de encadeamentos de computação (e, portanto, os membros de WebSphere Portal) pode variar de acordo com o aplicativo, mas esperamos que quatro a seis membros forneçam bom desempenho para a maioria dos aplicativos WebSphere Portal.

Use os seguintes comandos Solaris e siga estas etapas para fazer a configuração:

1. Insira pooladm –e para ativar o recurso de conjunto.
2. Insira pooladm –s para criar um arquivo de configuração estático que combine com a configuração dinâmica atual.
3. Insira poolcfg –c para criar wp_pset1 (unidade pset.min=20; unidade pset.max =21)’ para criar um conjunto de processadores chamado wp_pset1 com 20 a 21 processadores. Crie um conjunto de processadores para cada JVM de servidor de aplicativos, cada um com seu próprio nome.
4. Insira poolcfg –c para criar pool wp_pool1’ para criar um conjunto de recursos chamado wp_pool1. Crie um conjunto de recursos para cada conjunto de processador criado na etapa anterior, com nomes exclusivos para cada conjunto.
5. Insira poolcfg –c ‘associate pool wp_pool1(pset wp_pset1)’ para associar o conjunto de recursos com o conjunto de processadores. Use esse comando para cada conjunto de processador/par de conjunto de recursos.
   
   

   Os nomes usados acima para conjuntos de processadores e de recursos são arbitrários; os requisitos são que o nome do conjunto de processadores seja compatível com o nome do conjunto de recursos na etapa 5, e o nome do conjunto de recursos deve ser usado ao ligar a JVM ao conjunto de recursos na etapa 9.

6. Insira pooladm –c para executar a configuração em /etc/pooladm.conf.
7. Ligue os membros de cluster do WebSphere Portal a partir do console de administração do WebSphere Application Server.
8. Localize os IDs do processo para as JVMs do WebSphere Portal com o comando ps –ef | grep java. Há um ID de processo separado para cada JVM.
9. Insira poolbind –p wp_pool1 PortalPID. Esse comando liga o processo selecionado a um conjunto de recursos. Repita esse comando para cada JVM do portal, usando um conjunto de recursos separado para cada processo JVM.
   
   

   Se o WebSphere Portal for reiniciado, será preciso executar o comando poolbind com o novo ID de processo do WebSphere Portal. As etapas 1-6, porém, não precisam ser repetidas.

Podem ser encontradas mais informações sobre esses comandos no conjunto de documentação Solaris, Guia de Administração do Sistema: Gerenciamento de Recurso de Contêineres Solaris e Zonas Solaris em http://docs.sun.com.

Voltar para parte superior

Ajuste de servidor do WebSphere Portal

Instalamos o WebSphere Portal com a JVM padrão de 64 bits em Solaris, executada em kernel de 64 bits. O grande espaço de endereço de uma JVM de 64 bits permite um tamanho de heap grande; descobrimos que um heap de 3.5 GB fornece bom desempenho para esse aplicativo. Outros aplicativos podem ter seu desempenho otimizado com tamanhos de heap diferentes.

Todos os detalhes de ajuste para essa medição, abrangendo servidor de aplicativos, kernel Solaris, rede e outros componentes, são mencionados no Guia de Ajuste do WebSphere Portal, disponível em Guia de Ajuste do IBM WebSphere Portal Versão 6.1.x.

A Tabela 1 alista as principais configurações de ajustes para esse ambiente.

Voltar para parte superior

Comentários sobre o aplicativo

Qualquer ambiente com um grande número de encadeamentos de computação tem a possibilidade de encontrar problemas de desempenho se houver uma quantidade significativa de bloqueios dentro do aplicativo. Esse problema é exagerado em um ambiente como o Sun T5240. Visto que cada encadeamento de computação é um processador virtual relativamente lento, esse tipo de arquitetura de processador muitas vezes mantém os bloqueios por mais tempo do que em arquiteturas de processador mais convencionais.

Foi feito esforço significativo no WebSphere Portal V6.1 para reduzir o bloqueio dentro da estrutura do WebSphere Portal, reduzindo problemas de desempenho devido a bloqueio. O WebSphere Portal é uma estrutura de aplicativo que pode ser usada para executar uma grande variedade de aplicativos. Se os aplicativos (portlets) usados tiverem quantidades significativas de bloqueio, este pode se tornar um gargalo para o desempenho.

Voltar para parte superior

Conclusão

O WebSphere Portal pode ser executado em vários sistemas com arquiteturas totalmente diferentes. Os resultados mostrados aqui demonstram que ele pode alcançar boa capacidade em um sistema com grande número de encadeamentos de computação. Este artigo também explicou o ajuste e a configuração necessários para alcançar essa capacidade.

Recursos

• Participar do fórum de discussão.
  
  
• Leia mais sobre o WebSphere Portal no wiki de produto do WebSphere Portal.
  
  
• Consulte a página do produto WebSphere Portal em developerWorks.
  
  
• Consulte o Guia de Ajuste do IBM WebSphere Portal V6.1.

Sobre os autores

		Martin Presler-Marshall trabalha para otimizar o desempenho do WebSphere Portal e produtos relacionados. Ele escreveu o guia de resolução de problemas do WebSphere Portal além de contribuir para os guias de ajuste do WebSphere Portal. É possível entrar em contato com ele pelo e-mail mpresler@us.ibm.com.

		Laura Yen é engenheira de desempenho da equipe de desempenho do WebSphere nas instalações de Research Triangle Park da IBM. É possível entrar em contato com ela pelo e-mail lyen@us.ibm.com.

		Daniel Edwin gerencia o relacionamento técnico entre software Sun e IBM. Suas áreas de atuação incluem a otimização do desempenho e dimensionamento de software IBM para Sistemas Sun Solaris. Ele se interessa por código Java, Java EE, Solaris OS e ajuste de sistemas.

Avalie esta página

Reserve um instante para completar este formulário para nos ajudar a servi-lo melhor. As informações o ajudaram a alcançar seu objetivo? Sim Não Não sei   Faça comentários para ajudar a melhorar esta página:   Quão úteis são as informações? 1 2 3 4 5 Não são úteis Extremamente úteis

Voltar para parte superior