Dicas de resolução de problemas do componente de gerenciamento de carga de trabalho
Se o componente de gerenciamento de carga de trabalho não estiver distribuindo a carga de trabalho corretamente pelos servidores na configuração com vários nós, utilize as opções a seguir para isolar o problema.
- Assegure que a carga de trabalho seja distribuída entre os servidores em cluster.
- Resolva quaisquer problemas com a configuração do ambiente multisservidor do Deployment Manager.
- Eliminar problemas de ambiente ou de configuração
Procurar nos arquivos de log erros de WLM e códigos secundários CORBA
Analisar dados de PMI
- Resolver Problema ou Entrar em Contato com o IBM Support
Eliminar problemas de ambiente ou de configuração
- Há problemas de conexão de rede com os membros do cluster ou com os servidores administrativos, por exemplo, com o gerenciador de implementação ou os agentes de nós?
- Se houver, execute ping nas máquinas para assegurar-se de que estejam corretamente conectadas à rede.
- Há outra atividade nas máquinas nas quais os servidores estão instalados que esteja interferindo na capacidade dos servidores de atender um pedido? Por exemplo, verifique a utilização do processador medida pelo gerenciador de tarefas, pelo ID do processador ou por alguma outra ferramenta externa para ver se:
- Não é a esperada ou é errática em vez de constante.
- Mostra que um membro novo adicionado, instalado ou para o qual foi feito upgrade do cluster não está sendo utilizado.
- Todos os servidores de aplicativos que foram iniciados em cada nó estão em execução ou alguns estão parados?
- Os aplicativos estão instalados e operacionais?
- Se o problema estiver relacionado à distribuição da carga de trabalho por enterprise beans CMP (Container-Managed Persistence) ou BMP (Bean-Managed Persistence), você já configurou os provedores JDBC e a origem de dados JDBC de suporte em cada servidor?
Se você estiver tendo problemas de gerenciamento da carga de trabalho relacionados a pedidos HTTP, como pedidos HTTP não sendo atendidos por todos os membros do cluster, esteja ciente de que o plug-in HTTP equilibra a carga entre todos os servidores definidos na lista PrimaryServers se a afinidade não tiver sido estabelecida. Se você não tiver uma lista PrimaryServers definida, o plug-in equilibrará a carga entre todos os servidores que estiverem definidos no cluster se a afinidade não tiver sido estabelecida. Se a autorização tiver sido estabelecida, o plug-in deve ir diretamente a um determinado servidor para todos os pedidos.
- Os pesos estão definidos para os valores permitidos?
- Para o cluster em questão, efetue logon no console administrativo e:
- Selecione .
- Selecione seu cluster na lista.
- Selecione Membros de cluster.
- Para cada servidor no cluster, clique em server_name e anote o peso designado do servidor.
- Certifique-se de que os pesos estejam dentro do intervalo válido de 0-20. Se um servidor tiver um peso igual a 0, nenhum pedido será roteado para ele. Pesos maiores do que 20 são tratados como 0.
- Para o cluster em questão, efetue logon no console administrativo e:
O restante deste artigo lida somente com o equilíbrio da carga de trabalho do enterprise bean. Para obter mais ajuda no diagnóstico de problemas na distribuição de solicitações da web (HTTP), visualize os tópicos "Dicas de resolução de problemas do plug-in de servidor da web" e "O recurso da web não é exibido".
![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Procurar nos arquivos de log erros de WLM e códigos secundários CORBA
- Um servidor foi marcado como inutilizável mais de uma vez e permanece inutilizável.
- Todos os servidores de um cluster foram marcados como inválidos e permanecem inutilizáveis.
Um LSD (Location Service Daemon) foi marcado como inutilizável mais de uma vez e permanece inutilizável.
Para fazer isso,
utilize o Log and Trace Analyzer para abrir o registro de serviços
(activity.log) nos servidores afetados, e procurar as
seguintes entradas:
Para
fazer isso, abra o registro de serviço nos servidores afetados e procure as seguintes
entradas:
- WWLM0061W: Foi encontrado um erro ao enviar uma solicitação a
um membro de cluster member e esse membro foi
marcado como inutilizável para solicitações futuras ao cluster cluster.Nota: Não é fora do comum que um servidor seja marcado inutilizável. O servidor pode ser marcado como inutilizável por razões operacionais normais, como uma reinicialização em cadeia sendo executada enquanto ainda há uma carga no servidor de um cliente. Também é normal obter muitas mensagens de aviso WWLM0061W para um membro quase ao mesmo tempo. Geralmente há solicitações em processo em vários encadeamentos e após o membro ser marcado como indisponível, e os encadeamentos que direcionam esse membro provavelmente obterão essa mensagem de aviso.
- WWLM0062W: Foi encontrado um erro ao enviar uma solicitação ao membro de cluster member e esse membro foi marcado como inutilizável para solicitações futuras ao cluster cluster duas ou mais vezes.
- WWLM0063W: Foi encontrado um erro ao tentar usar o LSD LSD_name para resolver uma referência de objeto para o cluster cluster e ele foi marcado como inutilizável para solicitações futuras a esse cluster.
- WWLM0064W: Foram encontrados erros ao tentar enviar uma solicitação a todos os membros do cluster cluster e todos os membros foram marcados como inutilizáveis para solicitações futuras a esse cluster.
- WWLM0065W: Foi encontrado um erro ao tentar atualizar um membro de cluster server no cluster cluster, já que ele não podia ser alcançado a partir do gerenciador de implementação.
- WWLM0067W: o cliente recebe um aviso para repetir um pedido. Não foi
possível repetir um pedido do servidor de modo transparente devido à
exceção do WLM :{0}
Ao tentar atender a um pedido, o WML encontrou uma condição que não permitiria a nova submissão do pedido de modo transparente. A exceção de origem está sendo obtida, e um novo CORBA.TRANSIENT com código menor 0x49421042 (SERVER_SIGNAL_RETRY) está sendo emitido para o cliente.
- Uma possível resposta do usuário, como alteração de uma definição da configuração.
- Exceções da classe-base que possam indicar um defeito no produto.
Você também pode ver exceções com o "CORBA" como parte do nome da exceção, já que o WLM usa o CORBA (Common Object Request Broker Architecture) para comunicação entre processos. Procure por uma instrução na pilha de exceções especificando um "código secundário". Esses códigos denotam a razão específica pela qual uma chamada ou resposta CORBA não pôde ser concluída. Os códigos secundários do WLM estão no intervalo de 0x4921040 a 0x492104F. Para obter uma explicação dos códigos secundários relacionados ao WLM, consulte o tópico "Referência: Documentada da API gerada" para o pacote e classe com.ibm.websphere.wlm.WsCorbaMinorCodes.
![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Analisar dados de PMI
A finalidade para analisar os dados de PMI é entender a carga de trabalho que está chegando para cada membro de um cluster. Os dados para qualquer membro do cluster são úteis somente no contexto dos dados de todos os membros do cluster.
Utilize o Tivoli Performance Viewer para verificar se, com base nos pesos designados aos membros de cluster (os pesos com estado estável), cada servidor está obtendo a proporção correta dos pedidos.
- Selecione Coleta de Dados na visualização em árvore. Os servidores que não tiverem o PMI ativado ficarão esmaecidos.
- Para cada servidor cujos dados você deseja coletar, clique em Especificar...
- Agora você pode ativar as métricas. Defina o nível de monitoramento como baixo no painel Definição do Monitor de Desempenho
- Clique em OK
- Clique em Aplicar para que as alterações feitas entrem em vigor.
As métricas WLM PMI podem ser visualizadas em um servidor pela base de servidor. No Tivoli Performance Viewer, selecione
. Por padrão, os dados são mostrados na forma bruta em uma tabela e coletados a cada 10 segundos como um número agregado. Você também pode optar por ver os dados como um delta ou taxa, incluir ou remover colunas, limpar o buffer, redefinir as métricas para zero e alterar a taxa de coleta e o tamanho do buffer.Depois de ter obtido os dados de PMI, você deve calcular a porcentagem de numIncomingRequests para cada membro do cluster para o total de numIncomingRequests de todos os membros do cluster. Uma comparação desse valor percentual à porcentagem dos pesos direcionados a cada membro do cluster fornece uma visão inicial do equilíbrio da carga de trabalho direcionada a cada membro de um cluster.
Além de numIncomingRequests, duas outras métricas mostram como o trabalho é compensado entre os membros de um cluster, numincomingStrongAffinityRequests e numIncomingNonWLMObjectRequests. Essas duas métricas mostram o número de pedidos direcionados a um membro específico de um cluster que pode ser atendido somente pelo membro.
- Server1 = 5
- Server2 = 3
- Server3 = 2
- % roteada ao Server1 = weight1 / (weight1+weight2+weight3) = 5/10 ou 50%
- % roteada ao Server2 = weight2 / (weight1+weight2+weight3) = 3/10 ou 30%
- % roteada ao Server3 = weight3 / (weight1+weight2+weight3) = 2/10 ou 20%
Agora vamos considerar uma situação na qual não há pedidos recebidos com autorização forte nem nenhum pedido de objeto não-WLM.
- numIncomingRequestsServer1 = 390
- numIncomingRequestsServer2 = 237
- numIncomingRequestsServer3 = 157
Assim, o número total de pedidos sendo recebidos no cluster é: numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 784
numincomingStrongAffinityRequests = 0
numIncomingNonWLMObjectRequests = 0
- % (real) roteada ao Server1 = 390 / 784 = 49,8%
- % (real) roteada ao Server2 = 237 / 784 = 30,2%
- % (real) roteada ao Server3 = 157 / 784 = 20,0%
- Server1 = 5
- Server2 = 3
- Server3 = 2
- % roteada ao Server1 = weight1 / (weight1+weight2+weight3) = 5/15 ou 1/3 dos pedidos.
- % roteada ao Server2 = weight2 / (weight1+weight2+weight3) = 5/15 ou 1/3 dos pedidos.
- % roteada ao Server3 = weight3 / (weight1+weight2+weight3) = 5/15 ou 1/3 dos pedidos.
- numIncomingRequestsServer1 = 1236
- numIncomingRequestsServer2 = 1225
- numIncomingRequestsServer3 = 1230
- numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 3691
- numincomingStrongAffinityRequests = 445 e todas as 445 solicitações são direcionadas ao Server1.
- numIncomingNonWLMObjectRequests = 0.
- % (real) roteada para Server1 = 1236 / 3691= 33,49%
- % (real) roteada para Server2 = 1225 / 3691= 33,19%
- % (real) roteada para Server3 = 1230 / 3691= 33,32%
No entanto, a interpretação correta desses dados é que o roteamento de solicitações não está perfeitamente balanceado, porque Server1 tinha várias centenas de solicitações de afinidade forte. O WLM tenta compensar as solicitações de afinidade forte direcionadas a 1 ou mais servidores, distribuindo novas solicitações recebidas preferencialmente a servidores que não estão participando da afinidade transacional para compensar pelos servidores que estão participando de transações. No caso de solicitações recebidas com afinidade forte e solicitações de objetos não WLM, a análise seria análoga a esse caso.
Se, depois de ter analisado os dados de PMI e ter considerado a afinidade transacional e as solicitações de objetos não WLM, a porcentagem de solicitações recebidas reais para servidores em um cluster não reflete os pesos designados, isso indica que as solicitações não estão sendo balanceadas adequadamente. Se esse for o caso, recomenda-se repetir as etapas para eliminar problemas de ambiente e de configuração e procurar arquivos de log antes de continuar.
Resolver Problema ou Entrar em Contato com o IBM Support
Se os logs do cliente ou dos dados de PMI indicarem um erro no
WLM, colete as informações a seguir e entre em contato com o suporte IBM.
Se os logs do cliente indicarem um erro no WLM, colete as informações a seguir e entre em contato com o suporte IBM.
- Uma descrição detalhada de seu ambiente.
- Uma descrição dos sintomas.
Os arquivos SystemOut.logs e SystemErr.logs para todos os servidores no cluster.
Os arquivos de log do servidor para todos os servidores no cluster.
O arquivo activity.log.
Os arquivos de log de Primeira Captura de Dados com Falha.
As métricas de PMI.
- Uma descrição do que o cliente está tentando executar e uma descrição do cliente. Por exemplo, 1 encadeamento, vários encadeamentos, servlet, cliente J2EE, etc.
Se nenhuma destas etapas resolver o problema, verifique se o problema foi identificado e documentado usando os links no tópico "Diagnosticando e corrigindo problemas: recursos para aprendizado". Se não encontrar um problema semelhante ao seu ou se as informações fornecidas não resolverem seu problema, entre em contato com o suporte IBM para obter assistência adicional.
Se você não localizar seu problema listado lá,
entre em contato com o Suporte IBM.
Para obter as informações atuais disponíveis a partir do Suporte IBM
sobre problemas conhecidos e suas resoluções, veja a página Suporte IBM. Também é necessário consultar
essa página antes de abrir um PMR, pois ela contém documentos que
podem economizar seu tempo ao reunir as informações necessárias para resolver um problema.
Para obter as informações atuais disponíveis a partir do Suporte IBM
sobre problemas conhecidos e suas resoluções, veja a página Software IBM i. Também é necessário consultar
essa página antes de abrir um PMR porque ela contém informações
sobre os documentos que você tem que reunir e enviar para a IBM para receber
ajuda em algum problema.