Ajustando o Cache de EJB com Serviço de Rastreio

O tamanho do seu cache do Enterprise JavaBeans (EJB) pode afetar o desempenho do servidor de aplicativos. Uma das etapas no ajuste de seu contêiner EJB para níveis de desempenho ideais é fazer o ajuste fino do cache EJB.

Antes de Iniciar

Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM® i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL.

Sobre Esta Tarefa

O procedimento a seguir descreve como usar o serviço de rastreio de diagnóstico para ajudá-lo a determinar o melhor tamanho do cache.

Procedimento

  1. Ative o rastreio do cache de EJB. Para aprender a trabalhar com o serviço de rastreio, consulte o tópico Trabalhando com Rastreio. [IBM i][AIX Solaris HP-UX Linux Windows]Para obter informações sobre as configurações de serviço de rastreio, consulte o tópico Configurações de Serviço de Rastreio de Diagnóstico.
    Configure o rastreio para usar esta cadeia de rastreio:
    com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all=enabled:com.ibm.ejs.util.cache.CacheElementEnumerator=
    all=enabled

    [IBM i][AIX Solaris HP-UX Linux Windows]Configure Tamanho Máximo de Arquivo como 200MB ou mais. Se deixar esse valor-padrão de 20 MB, o único log de rastreio de 20 MB poderá ser preenchido e alguns dados poderão ser perdidos devido ao agrupamento de rastreio.

    [IBM i][AIX Solaris HP-UX Linux Windows]Configure o Número Máximo de Arquivos de Histórico como 5. Cinco arquivos devem ser suficientes, mas se você vir que todos os cinco arquivos estão cheios e que ocorre agrupamento do rastreio, aumente esse valor.

  2. [IBM i][AIX Solaris HP-UX Linux Windows]Pare o servidor, exclua os logs existentes e, em seguida, inicie o servidor.
  3. [z/OS]Pare e reinicie o servidor.
  4. Execute cenários típicos para capturar dados de rastreio do cache. Ao executar um cenário típico com o rastreio ativado, os dados de rastreio de cache EJB serão recebidos para serem analisados nas seguintes etapas.
  5. Visualize e analise a saída de rastreio.
    1. Abra o log de rastreio. Procure por uma ou pelas duas seguintes sequências de rastreio a serem exibidas:

      [IBM i][AIX Solaris HP-UX Linux Windows]Cache de EJB BackgroundLru 3: Tempo de acesso (1,40) - Limite de cache não atingido : 489/2053
      BackgroundLru >  EJB Cache: Sweep (16,40) - Cache limit exceeded : 3997/2053 Entry

      [z/OS] Trace: 2007/03/22 11:47:07.048 01 t=7A9690 c=UNK key=P8 (13007002)
      ThreadId: 0000006a
      FunctionName: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
      SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
      Categoria: FINEST
      ExtendedMessage: Cache de EJB: Tempo de acesso (23,40) - Limite de cache não atingido : 0/2053

      Rastreio: 2007/03/22 11:54:16.755 01 t=7BD3B0 c=UNK key=P8 (13007002)
      ThreadId: 0000006d
      FunctionName: EJB Cache: Tempo de acesso (75,37) - Limite de cache excedido : 3801/2053
      SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
      Categoria: FINER
      ExtendedMessage: Entrada

      Nas cadeias de rastreio que incluem as palavras Limite de cache, você encontrará uma proporção. Por exemplo, 3997/2053. O primeiro número é o número de enterprise beans atualmente no cache de EJB (chamado de capacidade). O segundo número é a configuração do cache de EJB (mais detalhes sobre isto em etapas posteriores). Use essa proporção, especialmente a capacidade, na sua análise.

      Também procure pelas frases Limite de cache não atingido e Limite de cache excedido.
      Limite de cache não atingido
      Seu cache é igual a ou maior que o apropriado. Se for maior, estará perdendo memória e deverá reduzir o tamanho do cache para um valor mais apropriado.
      Limite de cache excedido
      O número de beans que estão sendo utilizados atualmente é maior que a capacidade especificada, indicando que seu cache não está ajustado corretamente. A capacidade pode exceder a configuração do Cache de EJB porque a configuração não é um limite rígido. O Contêiner EJB não para de incluir beans no cache quando o limite é atingido. Se isso fosse feito, quando o cache estivesse cheio um pedido de um bean não seria atendido, ou pelo menos seria retardado até que o cache caísse abaixo do limite. Em vez disso, o limite do cache pode ser excedido, mas o Contêiner EJB tenta limpar o cache e mantê-lo abaixo do tamanho do Cache de EJB.
      Caso o limite do cache seja excedido, você poderá ver um ponto de rastreio semelhante a este:

      [IBM i][AIX Solaris HP-UX Linux Windows]BackgroundLru <  Cache de EJB: Tempo de acesso (64,38) - Despejado = 50 : 3589/2053 Saída

      [z/OS] Cache EJB: Sweep (64,38) - Despejado  = 50 : 3589/2053

      Observe a cadeia Despejado =. Se você vir essa cadeia, estará utilizando Beans de Sessão com Preservação de Estado ou Beans de Entidade configurados para o armazenamento de cache Opção A ou B. Objetos despejados significam que você não está aproveitando totalmente a opção de armazenamento em cache que escolheu. O primeiro passo é tentar aumentar o tamanho do Cache de EJB. Se a continuação de execução do seu aplicativo resultar em mais despejos, isso significa que o aplicativo está acessando ou criando mais novos beans entre as trocas de Cache EJB do que o cache pode suportar e NÃO está reutilizando os beans existentes.
      Você pode querer considerar o uso do armazenamento em cache da Opção C para seus beans de entidade ou verificar seu aplicativo para ver se ele não está removendo Beans de Sessão Stateful depois que eles não forem mais necessários.
      Nota: Os Beans de Entidade configurados com a Opção C de armazenamento em cache estão no cache apenas enquanto estiverem em uma transação, e precisam ser mantidos no cache por toda a transação. Portanto, eles nunca são despejados durante um tempo de acesso do cache, mas são removidos do cache quando a transação é concluída. Além disso, se você estiver utilizando apenas Beans de Sessão sem Estado ou Beans de Entidade com a Opção C de armazenamento em cache (ou ambos), poderá aumentar o intervalo de limpeza do Cache de EJB para um número maior. O intervalo de limpeza pode ser configurado conforme descrito nas configurações do cache EJB. Os Beans de Sessão Stateless NÃO estão no Cache EJB e, como os Beans de Entidade que usam o armazenamento em cache da Opção C nunca são despejados pela estratégia de armazenamento em cache (LRU), não há nenhuma necessidade real de tempo de acesso com frequência. Ao usar apenas Beans de Sessão Stateless ou o armazenamento em cache da Opção C, você deverá ver apenas "Evicted = 0" no exemplo de rastreio mostrado.
    2. Analise o log de rastreio. Procure a cadeia de rastreio Limite de cache excedido.
      • É possível encontrar mais de uma instância dessa cadeia. Examine todas elas para localizar o valor da maior capacidade de beans no Cache de EJB. Reconfigure seu tamanho de Cache EJB para cerca de 110% desse número. A configuração do tamanho do Cache de EJB é explicada em uma etapa posterior.
      • É possível não encontrar nenhuma instância dessa cadeia. Isso significa que você não excedeu a capacidade do Cache de EJB (o que é sua meta final), mas não vê-la durante a análise inicial também poderia significar que seu cache é grande demais e está utilizando memória desnecessária. Neste caso, você ainda deverá sintonizar seu cache reduzindo o tamanho do cache até seu limite de cache não ser excedido, em seguida, aumentando-o para o valor ideal. A configuração do tamanho do Cache de EJB é explicada em uma etapa posterior.
      Sua meta final é configurar o limite do cache como um valor que não desperdice recursos mas também não seja excedido. Uma boa configuração fornece um rastreio com apenas a mensagem Limite de cache não atingido, e uma proporção em que o número da capacidade possa chegar próximo, mas abaixo de 100% da configuração de Cache EJB.
      Nota: É recomendado não configurar seu tamanho de cache para algo menor que o padrão de 2053.
  6. Modifique as configurações de cache com base na análise. Consulte as configurações de cache EJB para obter informações sobre como fazer isso.
  7. [IBM i][AIX Solaris HP-UX Linux Windows]Para o servidor, exclua todos os logs e reinicie o servidor.
  8. [z/OS]Pare e reinicie o servidor.
  9. Repita as etapas anteriores até que esteja satisfeito com suas configurações.
  10. Desative o rastreio do Cache de EJB. Com o cache ajustado corretamente, é possível remover o rastreio, remover os logs antigos e reiniciar o servidor.

O que Fazer Depois

A partir de sua análise, é possível configurar o cache EJB de forma ideal, de uma perspectiva de Contêiner EJB, mas talvez não de forma ideal de uma perspectiva do WebSphere Application Server. Um tamanho de cache maior resulta em mais acertos e melhor desempenho do cache, mas utiliza mais memória. A memória utilizada pelo cache não está disponível para outras áreas do produto, possivelmente causando impacto sobre o desempenho geral. Em um sistema com memória ampla, isso pode não ser um problema e um ajuste correto do cache de EJB pode melhorar o desempenho geral. No entanto, você deve levar em conta essa questão de desempenho do sistema versus desempenho do cache de EJB ao configurar o cache.


Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_tunecash
Nome do arquivo: tejb_tunecash.html