Cenário: Você está tendo problemas com o
desempenho, como:
Tempos de resposta ruins no workbench ao desenvolver fluxos de mensagens
Tempo de resposta ruim na implementação
Mensagens individuais levam muito tempo para serem
processadas
Desempenho geral fraco ou desempenho que não escala bem
Solução: As soluções possíveis são:
Acelerar as mensagens persistentes do WebSphere MQ
otimizando a E/S (Entrada/Saída)
Acelerar o acesso ao banco de dados otimizando a E/S
Aumentar a memória do sistema
Utilizar instâncias adicionais ou vários grupos de execução
Otimizar instruções ESQL para o melhor desempenho
Uma boa fonte de informações sobre desempenho é o
conjunto de relatórios em WebSphere MQ
SupportPacs da Categoria de Família 2 (freeware), disponíveis para
download em Página
da Web dos WebSphere MQ SupportPacs.
Este
tópico contém avisos para lidar com alguns problemas comuns que podem
surgir:
Cenário: O sistema está se tornando cada vez mais lento.
Explicação: Quando um processo é encerrado de forma
anormal, uma entrada é feita no
log de erros local e um arquivo de dados de
dump pode ser gravado no diretório errors ou registro do
z/OS.
Esse diretório é ilimitado e se você não o limpar de arquivos indesejáveis, o
desempenho do sistema poderá se degradar devido ao uso de espaço significativo
por arquivos de abortos antigos.
Solução: No Windows,
é aconselhável utilizar o sinalizador -w do comando
mqsicreatebroker
para criar o diretório de erros em uma partição do disco rígido que não contém o
WebSphere Message Broker nem o Windows nele.
Você está Tendo Problemas de Configuração com Um Grande Número de Componentes
Cenário: Você está tendo problemas de configuração
com um grande número de componentes.
Explicação: Se você estiver executando o
WebSphere Message Broker com um grande número de
componentes configurados, a ocupação da memória dos processos do
intermediário (principalmente o DataFlowEngine) pode exceder os
limites de memória.
Em particular, o limite de processos do usuário pode
ser excedido ou o limite do espaço de endereçamento pode ser alcançado. Você pode encontrar problemas, como a mensagem de erro
BIP2106E, ao executar um intermediário com:
Um grande número de fluxos de mensagens
Vários bancos de dados
Mensagens de entrada ou de saída muito grandes
Solução: Utilize as ferramentas específicas para o sistema operacional
para verificar o tamanho máximo do processo com falha, em seguida, verifique quaisquer
limites do usuário (se aplicável) ou limites do computador no tamanho do processo.
Utilize o comando ulimit para verificar os limites do
usuário em sistemas Linux ou UNIX
e aumentar, se necessário.
Há um limite fixo em cada sistema operacional
para o tamanho máximo de processos, além do qual a falha é inevitável:
Sistema operacional
Tamanho Máximo do Processo
Windows
2 GB
Solaris
Aproximadamente 3,75 GB
HP-UX
Aproximadamente 3 GB, dependendo de definições do kernel
AIX (sistema de 32 bits)
2 GB
z/OS
2 GB
Aumentar os limites do usuário além desses valores não fará nenhuma diferença.
Se seus processos do intermediário atingirem regularmente esses tamanhos, considere espalhar
seus fluxos de mensagens por mais grupos de execução para reduzir o tamanho
de cada um deles para abaixo desses limites.
No AIX, o WebSphere Message Broker limita
DataFlowEngines a dois segmentos de memória de 256 MB, ou seja, a 512 MB. Normalmente, os processos
DataFlowEngine não exigem mais que 512 MB do espaço de endereços do AIX e por isso o arquivo executável DataFlowEngine é vinculado, de forma a ter um espaço de
endereços padrão de 2 segmentos. Contudo, é possível estender o tamanho do
espaço de endereços AIX disponível para o processo
DataFlowEngine, aumentando o número de segmentos de memória de 256 MB disponíveis
para ele. Você pode corrigir o DataFlowEngine para utilizar mais segmentos de memória,
utilizando os seguintes comandos shell:
Cria uma versão do DataFlowEngine que utiliza quatro
segmentos (ou seja, 1 GB).
Ou então,
no AIX 5.1 e superior, você pode alcançar
o mesmo resultado, utilizando o comando do ldedit:
ldedit -b maxdata:0x40000000 DataFlowEngine
O aplicativo de manutenção do fix substitui o DataFlowEngine existente,
assim, se você tiver utilizado o processo acima, precisará repeti-lo após cada instalação
do fix pack.
A técnica descrita acima substitui somente o limite de
software e não o de hardware. Se os processos de intermediário alcançarem esses tamanhos regularmente, considere
espalhar os fluxos de mensagens por mais grupos de execução para reduzir o tamanho
de cada um deles para que fiquem abaixo desses limites.
Um Loop WHILE em uma Matriz XML Grande Leva Muito Tempo para
Processar
Cenário: Um loop WHILE em uma matriz XML grande
leva muito tempo para processar.
Explicação: Você provavelmente está utilizando a
função CARDINALITY() para determinar o tamanho da matriz no elemento
WHILE.
Isso não é recomendável, pois com matrizes grandes o custo para
determinar o número de elementos é proporcional ao tamanho da matriz. A função CARDINALITY
é chamada sempre que a instrução WHILE é executada. Como a mensagem
tem muitos elementos, há uma carga significativa ao executar o
loop dessa maneira.
Solução: A menos que você tenha uma mensagem na
qual o número de elementos da matriz cresce de forma dinâmica,
determine o tamanho da matriz antes de digitar o loop WHILE.
Utilize código semelhante ao seguinte:
DECLARE i,c INTEGER;
SET i = 1;
SET c=CARDINALITY(OutputRoot.XML.MyMessage.Array[ ]);
WHILE i <= c DO
. . .
. . . loop processing
. . .
END WHILE;
Chamadas waitForMessages Remotas com
WebSphere MQ Everyplace São Lentas
Cenário: Chamadas waitForMessages remotas com
WebSphere MQ Everyplace são lentas.
Explicação: Isso ocorre pois uma chamada
waitForMessages() remota resulta necessariamente em uma ação de
polling: o gerenciador de filas do cliente tenta obter uma mensagem
repetidamente até uma estar disponível na fila remota ou um tempo
limite ser alcançado.
Solução: Defina uma fila store-and-forward no gerenciador de filas do
intermediário e uma fila home-server no cliente.
Isso fornece um nível maior de desacoplamento e permite que o arranjo funcione
no caso do gerenciador de filas do cliente se tornar indisponível. Ou então, especifique uma fila remota
no nó de saída do WebSphere MQ Everyplace, de forma que uma chamada
GET local seja suficiente do lado do cliente.
Há uma Perda no Desempenho para Procedimentos Armazenados
Cenário: Os procedimentos armazenados que não retornam os conjuntos de resultados,
não têm um desempenho semelhante ao que teriam ao utilizar os drivers do DataDirect versão 4.1.
Explicação: Os novos drivers do DataDirect versão 5 Oracle
utilizam agora o parâmetro de configuração ProcedureRetResults, para
permitirem que o driver retorne os conjuntos de resultados dos procedimentos armazenados. Esse
parâmetro aplica-se apenas ao Oracle. Por padrão, o parâmetro é configurado como 1 e
precisa ser 1, se você utilizar os procedimentos armazenados que retornam conjuntos de resultados. Quando esse
parâmetro for configurado como 0, o driver não retorna os conjuntos de resultados
dos procedimentos armazenados e isso pode resultar em melhor desempenho.
Solução: Se seus procedimentos armazenados não retornarem nenhum conjunto de
resultado, configure o parâmetro ProcedureRetResults como 0 (zero).