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 do
WebSphere MQ SupportPacs.
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 não tem limite e se você não limpá-lo dos arquivos indesejados, poderá verificar que o desempenho de seu sistema diminui devido a um espaço significativo sendo utilizado por antigos arquivos de aborto.
Solução: No Windows,
você é aconselhado a utilizar o parâmetro -w do comando mqsicreatebroker para criar o diretório errors em uma partição de unidade de disco rígido que não contém o WebSphere Message Broker ou o Windows em si.
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 de usuário nos 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 pack substitui o DataFlowEngine existente, portanto, se tiver utilizado o processo acima, repita-o após cada instalação de 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 grandes matrizes, o custo de determinação do 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 exemplo a seguir:
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ó output 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).
Você está experimentando baixo desempenho no workbench quando
trabalha com projetos grandes
Cenário:você está experimentando baixo desempenho no workbench ao trabalhar com projetos grandes ou complexos.
Explicação: se você estiver experimentando baixo desempenho decorrente
das freqüentes alterações no projeto, como incluir e remover projetos, ou utilizando Projeto > Limpar,
é porque as atualizações completas do projeto utilizam grandes quantidades de memória por causa
do tamanho, do número e das conexões entre os arquivos.
Solução: aumente a memória do sistema.
O PutTime Relatado pelo WebSphere MQ no z/OS e Outros Horários ou Time Stamps Estão Inconsistentes
Cenário: O PutTime relatado pelo WebSphere MQ no z/OS e outros horários ou time stamps estão inconsistentes.
Uma diferença de aproximadamente 20 segundos é detectada em:
rastreios (incluindo a obtida do nó Trace)
o time stamp MQPUTTIME no cabeçalho MQMD da mensagem
time stamps obtidos do ESQL (por exemplo, em um nó Compute)
Explicação: WebSphere Message Broker relata o horário utilizando UTC (Universal Time Coordinated), que não considera os segundos saltados. No entanto, no z/OS, o
putTime da mensagem que é relatado pelo WebSphere MQ no cabeçalho MQMD de uma mensagem considera os segundos saltados, utilizando o valor especificado para o número de segundos saltados no campo CVT.
Essa inconsistência pode causar:
problemas ao depurar
problemas com fluxos de mensagens se você utilizar time stamps para controlar o fluxo de mensagens
informações incorretas
Solução: Configure o campo CVT de forma que concorde com os segundos saltados de UTC. Como alternativa, inclua um deslocamento para ajustar a leitura de time stamp do z/OS. Por exemplo, inclua 20 segundos ao tentar obter o CURRENT_TIME em
ESQL.