Como resolver uma fuga de memória ou uma excepção de memória esgotada no processo do servidor de BizTalk

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 918643
Sumário
Fugas de memória são um problema comum. Poderá ter de experimentar vários passos para identificar a causa específica de uma fuga de memória ou de uma excepção (OOM) de memória esgotada no Microsoft BizTalk Server. Este artigo aborda questões importantes a considerar quando está a avaliar a utilização da memória e eventuais problemas relacionadas com a memória. Estas considerações incluem o seguinte:
  • RAM física
  • Processamento de mensagens grandes
  • Utilizar o /3GB parâmetro
  • Utilização de componentes personalizados
  • Qual a versão do Microsoft .NET Framework que o sistema está com
  • O número de processadores
INTRODUÇÃO
Este artigo descreve como resolver uma fuga de memória ou uma excepção de memória esgotada no processo do servidor BizTalk do Microsoft BizTalk Server.
Mais Informação
O processo do servidor BizTalk pode estar a ocorrer uma fuga de memória quando a utilização da memória no Gestor de tarefas do Microsoft Windows consome mais do que 50 por cento da memória RAM física. Uma fuga de memória pode causar uma excepção de memória esgotada quando a utilização da memória aumenta até o processo é executado sem memória de sistema ou até que o processo deixa de funcionar.

Quando este problema ocorre, uma mensagem de aviso semelhante à seguinte é registada no registo de eventos:

Tipo de evento: aviso
Categoria do evento: (1)
ID do evento: 5410
Descrição: Ocorreu um erro que requer que o serviço de BizTalk para terminar. As causas mais comuns são uma inesperado do erro de memória e numa incapacidade de ligar ou perda de conectividade a uma das bases de dados BizTalk. O encerramento do serviço será e reiniciar automaticamente dentro de 1 minuto. Se a base de dados problemático permanece indisponível, vai repetir este ciclo.
Mensagem de erro: excepção do tipo System.OutOfMemoryException accionada.
Origem do erro:
Nome de anfitrião do BizTalk: BizTalkServerApplication
Nome de serviço do Windows: BTSSvc {DCC899FE-C62F-41BE-851A-8720B2EB9C14}

Tipo de evento: aviso
Categoria do evento: (1)
ID do evento: 5410
Descrição: Ocorreu um erro que requer que o serviço de BizTalk para terminar. As causas mais comuns são os seguintes: 1) erro de memória de uma inesperado esgotada. OU 2) uma incapacidade de ligar ou perda de conectividade a uma das bases de dados BizTalk. O encerramento do serviço será e reiniciar automaticamente dentro de 1 minuto. Se a base de dados problemático permanece indisponível, vai repetir este ciclo.
Mensagem de erro: excepção do tipo 'System.OutOfMemoryException' foi accionada.
Origem do erro: mscorlib
Nome de anfitrião do BizTalk: BizTalkServerApplication
Nome de serviço do Windows: BTSSvc$ BizTalkServerApplication

Considerações importantes

Utilização de RAM e memória física

Porque é um comportamento esperado para um processo utilizam cerca de metade da RAM física, utilize a utilização da memória como orientação. Por exemplo, se o servidor BizTalk tiver 4 gigabytes (GB) de RAM e o processo do servidor BizTalk utiliza cerca de 500 megabytes (MB) de RAM, não haja fuga. Se o processo do servidor BizTalk utiliza cerca de 1 GB de RAM, poderá existir uma fuga de memória ou uma situação de memória alta. O consumo de memória pode ser causado por um procedimento armazenado de execução demorada ou orchestration. Certifique-se de que sabe como quantidade de memória que o anfitrião de BizTalk normalmente utiliza para determinar se uma fuga de memória ou a condição de memória superior está a ocorrer.

Mensagens grandes

Quando o BizTalk Server processa mensagens grandes, o sistema parece ter uma fuga de memória. No entanto, as mensagens podem estar a utilizar uma grande quantidade de memória. Para mais informações sobre mensagens de grandes dimensões, visite os seguintes Web sites da Microsoft Developer Network (MSDN): Além disso, considere a utilização de memória alta pode esperar que se BizTalk Server está a processar mensagens grandes. Poderá pretender actualizar o hardware para cumprir os requisitos de desempenho do BizTalk Server no seu ambiente.

Quanto tempo demora a reproduzir a fuga de memória

Fugas de memória podem ocorrer imediatamente ou podem acumular-se ao longo do tempo. Ambos os cenários são comuns.

Utilização do parâmetro /3GB em computadores de 32 bits

Normalmente, um processo pode aceder a 2 GB de espaço de endereçamento virtual. O parâmetro /3GB é uma opção para sistemas que necessitem de mais memória endereçável. Esta opção poderá melhorar a utilização da memória para o processamento de mensagens. No entanto, o parâmetro /3GB permite apenas 1 GB de memória endereçável para operações de modo kernel. Além disso, este parâmetro pode aumentar o risco da falta de memória de conjunto.

Para mais informações sobre os /3GB mudar, visite o seguinte Web site da Microsoft Developer Network (MSDN): Quando o parâmetro /3GB está activado numa versão de 32 bits do Windows, o processo pode aceder a 3 GB de espaço de endereçamento virtual se o processo for grande endereço tenha em atenção. Um processo é grande endereço tenha em atenção quando o ficheiro executável tem o sinalizador IMAGE_FILE_LARGE_ADDRESS_AWARE definido no cabeçalho da imagem. Uma vez que o processo de BizTalk é grande endereço tenha em atenção que BizTalk beneficiarão do parâmetro /3GB.

Se uma instância de sistema anfitrião do BizTalk de 32 bits estiver a executar uma versão de 64 bits do Windows (AMD64), as vantagens do processo de BizTalk da memória de 4 GB espaço de endereços porque BizTalk é grande endereço tenha em atenção. Por conseguinte, se mover as aplicações de memória superior a um servidor de 64 bits, poderá ser a melhor solução.

Um processo de BizTalk de 64 bits numa versão de 64 bits do Windows (AMD64) tem 8 TB de memória endereçável.

Também deve considerar os bytes virtuais e os bytes privados utilizados pelo processo. Uma instância de sistema anfitrião do BizTalk (o que é uma aplicação .NET Framework) poderá receber uma erro de memória esgotada antes do valor de bytes do espaço Virtual atinge 2 GB. Isto pode ocorrer mesmo que o máximo de memória endereçável por um processo numa versão de 32 bits do Windows (sem o parâmetro /3GB ) é de 2 GB. Para obter uma explicação do motivo pelo qual esta situação pode ocorrer, visite os seguintes Web sites da Microsoft Developer Network (MSDN): O parâmetro /3GB também aumenta o número máximo de bytes privado do processo de BizTalk do 800 MB para 1800 MB. Para mais informações sobre o desempenho de aplicações do .NET Framework com o parâmetro /3GB activado, visite o seguinte Web site da Microsoft Developer Network (MSDN): A tabela seguinte resume estas informações e inclui os limites de práticos para bytes virtuais e bytes privados.
ProcessoWindowsMemória endereçável (com um processo com detecção de endereços grande)Limite prático para bytes do espaço virtuaisLimite prático para bytes privados
32-bit32-bit2 GB1400 MB800 MB
32-bit32-bit com 3 GB3 GB2400 MB1800 MB
32-bit64 bits4 GB3400 MB2800 MB
64 bits64 bits8 TBNão aplicávelNão aplicável
Para mais informações sobre a memória endereçável para 32 bits versus 64 bits do Windows, visite o seguinte Web site da Microsoft Developer Network (MSDN): A tabela seguinte lista de compatibilidade PAE e 3GB para diferentes versões do BizTalk Server.
ProdutoPAE3GB
O BizTalk Server 2004SimNão
BizTalk Server 2006SimSim
BizTalk Server 2006 R2SimSim
BizTalk Server 2009SimSim
Se tem de activar o parâmetro /3GB satisfazer os requisitos de desempenho de um computador com o BizTalk Server, poderá considerar a adição de servidores para o grupo de BizTalk. Isto permite-lhe por escalar para fora das instâncias de anfitrião que utilizem muita memória.

BizTalk componentes que são executados dentro de um processo de serviços de informação Internet (IIS) também podem beneficiar, quando o parâmetro /3GB está activado.

O parâmetro /3GB não é suportado em computadores que executem o Windows SharePoint Services 2.0 ou versões posteriores ou o SharePoint Portal Server 2003 SP2 ou versões posteriores. Para mais informações, clique no número de artigo seguinte para visualizar o artigo na Base de Dados de Conhecimento Microsoft
933560 O parâmetro /3GB do Windows Server 2003 não é suportado no Windows SharePoint Services 2.0 ou versões posteriores ou no SharePoint Portal Server 2003 Service Pack 2 ou de versões posteriores

Utilização de componentes personalizados

Se utilizar componentes personalizados, tais como condutas ou componentes de serviço, tem de saber o que fazer estes componentes. Também tem de saber o efeito potencial destes componentes na utilização da memória. Um problema de memória comum ocorre quando um componente está a transformar um documento. A operação de transformação é uma operação que utilizem muita memória. Quando um documento é transformado, BizTalk Server transmite a sequência de mensagem para a classe de Microsoft de .NET Framework XslTransform no âmbito do processo de BizTalk.

Outro problema comum ocorre quando existe manipulação da cadeia intensiva. Manipulação de cadeia intensiva pode consumir muita memória. Para mais informações sobre formas de melhorar o desempenho, visite o seguinte Web site da Microsoft Developer Network (MSDN):

Versão do .NET Framework

Microsoft .NET Framework 2.0 e o .NET Framework 1.1 têm o comportamento de memória diferente. Por conseguinte, poderá ver vários resultados entre eles. Se estiver a utilizar o .NET Framework, confirme que o .NET Framework Service Pack 1 mais recente está instalado. Estes service packs resolvem vários problemas conhecidos de memória. Para mais informações, clique nos números de artigo seguinte:

945757 Problemas corrigidos no .NET Framework 2.0 Service Pack 1
867460 Lista de erros corrigidos no .NET Framework 1.1 Service Pack 1

Número de processadores

O common language runtime (CLR) tem o colector de lixo (GC) seguintes:
  • Estação de trabalho (Mscorwks.dll)
  • Servidor (Mscorsvr.dll)
Se o computador com o BizTalk Server é um sistema multiprocessador, o .NET Framework utiliza a versão de servidor do motor de execução. Este é o comportamento predefinido. Recolector de lixo de servidor foi concebido para o débito máximo. Além disso, o recolector de lixo de servidor pode ser dimensionado para fornecer um desempenho muito alto. Este recolector de lixo atribui memória e, em seguida, mais tarde liberta memória para fornecer o alto desempenho no sistema. Por conseguinte, um computador com o BizTalk Server e alguns componentes do .NET Framework parece ter uma fuga de memória. No entanto, neste cenário, a elevada utilização da memória é o comportamento esperado. Se o computador ficar sem memória do sistema, ou se o processo deixa de funcionar devido à memória endereçável insuficiente, poderá existir uma condição de fuga de memória.

Se o computador com o BizTalk Server é um sistema de processador único, o .NET Framework utiliza a versão de estação de trabalho do motor de execução. Este é o comportamento predefinido. O algoritmo de atribuição de lixo de estação de trabalho não foi concebido para o dimensionamento ou para um débito máximo. Este recolector de lixo utiliza métodos de Recolector de lixo em simultâneo. Estes métodos são concebidos para aplicações com interfaces de utilizador complexos. Tais aplicações podem exigir mais agressiva recolha de lixo.

Importante Esta secção, método ou tarefa contém passos que explicam como modificar o registo. No entanto, poderão ocorrer problemas graves se modificar o registo incorrectamente. Por conseguinte, certifique-se de que segue estes passos cuidadosamente. Para uma maior protecção, efectue o backup do Registro antes de o modificar. Em seguida, pode restaurar o registo se ocorrer um problema. Para mais informações sobre como efectuar cópias de segurança e restaurar o registo, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
322756 Como efectuar cópias de segurança e restaurar o registo no Windows
Por vezes, poderá ser adequado executar a versão de estação de trabalho do motor de execução num sistema com múltiplos processadores. Pode utilizar a seguinte chave de registo para mudar para a versão de estação de trabalho do motor de execução.

BizTalk 2006 e versões posteriores

Crie a seguinte chave de registo de cadeia de hospedagem da CRL com os valores correspondentes:

Hospedagem de \CLR do HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName

Nome: sabor
Dados: wks

BizTalk 2004

Crie a seguinte chave de registo de cadeia de hospedagem da CRL com os valores correspondentes:

Anfitrião \CLR HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc {GUID}

Nome: sabor
Dados: wks

Para mais informações, visite os seguintes Web sites da Microsoft Developer Network (MSDN):

Causas comuns e resoluções

A utilização da memória de processos e a utilização de memória física que optimizar limiares

A utilização de memória de processos e a utilização da memória física optimização limiares podem ser alterada no BizTalk Server 2006 e em versões posteriores.
  • Por predefinição, a utilização de memória de processos optimização limiar é definida como 25. Se este valor for excedido e a utilização de memória do processo de BizTalk é superior a 300 MB, poderá ocorrer uma condição de optimização. Num servidor de 32 bits, pode aumentar o valor de utilização de memória do processo para 50. Num servidor de 64 bits, pode aumentar este valor para 100. Isto permite mais consumo de memória pelo processo de BizTalk antes da ocorrência da optimização.
  • A utilização da memória física optimização limiar tem um valor predefinido de 0. Este limiar medidas memória total do sistema. Por conseguinte, se for configurado um valor diferente de 0, uma condição de optimização pode ocorrer se um processo de BizTalk não estiver a utilizar memória alta.
Para mais informações sobre os limiares de optimização, visite o seguinte Web site da Microsoft Developer Network (MSDN):

Optimização de limiares de desidratação

Os limiares de desidratação de memória predefinido podem causar demasiado desidratação quando orchestrations são executadas num anfitrião de 64 bits. Para mais informações sobre este problema, consulte o tópico de Propriedades predefinidas de desidratação sobre o seguinte Web site da Microsoft Developer Network (MSDN): Nota 64-bit anfitriões são suportados no BizTalk Server 2006 e versões posteriores.

Em hardware equivalente numa instância de anfitrião de 32 bits, desidratação observada é nominal quando os mesmos orchestrations são executados utilizando a desidratação de memória predefinido limiares de optimização.

Uma vez que a arquitectura de 64 bits fornece espaço de endereços de memória expandida (16 TB em vez de 4 GB), são atribuídas a instâncias de anfitrião de 64 bits significativamente mais memória do que instâncias de anfitrião de 32 bits. Isto pode causar os limiares de optimização de memória predefinido deve ser ultrapassada.

Para contornar este comportamento, altere os valores VirtualMemoryThrottlingCriteria e PrivateMemoryThrottlingCriteria no ficheiro BTSNTSvc64.exe.config. Utilize os Bytes de Process\Virtual e os contadores do Monitor de desempenho Process\Private Bytes para determinar a quantidade maior de memória que está a ser atribuída por uma instância de orchestration.
  • Defina o valor de OptimalUsage para ambas as propriedades com base no seguinte:
    VirtualMemoryThrottlingCriteria: valor de Bytes de \Process\Virtual + 10 %)
    PrivateMemoryThrottlingCriteria: valor de Bytes de \Process\Private + 10 %)
  • Definir MaximalUsage para ambas as propriedades para o valor de OptimalUsage + 30%
Por exemplo, se o valor de contador do Monitor de desempenho de Bytes para uma instância de orchestration \Process\Virtual for 5,784,787,695 bytes (5,517 MB), defina o valor de OptimalUsage para VirtualMemoryThrottlingCriteria a 6,069 MB (5,784,787,695 * 1.10 = 6,363,266,464.5 bytes). Defina o valor de MaximalUsage para VirtualMemoryThrottlingCriteria a 7,889 MB (6,363,266,464.5 * 1.30 = 8,272,246,403.85 bytes).

Se o valor de contador do Monitor de desempenho de Bytes de \Process\Private for 435689400 bytes (415 MB), defina o valor de OptimalUsage para PrivateMemoryThrottlingCriteria a 457 MB (435689400 * 1.10 = 479258340 bytes). Defina o valor de MaximalUsage para PrivateMemoryThrottlingCriteria a 594 MB (479258340 * 1.30 = 623035842).

Neste exemplo, os seguintes valores teriam de ser especificados no ficheiro BTSNTSvc64.exe.config para reduzir a aceleração.
Contador do Monitor de desempenhoMemória atribuídaOptimalUsageMaximalUsage
\Process\Virtual bytes5784787695 bytes (5517 MB)60697889
\Process\Private bytes435689400 bytes (415 MB)457594
Estes valores seriam, em seguida, representados no ficheiro BTSNTSvc64.exe.config do seguinte modo:
<xlangs>      <Configuration>                  <Dehydration>                              <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />                              <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />                  </Dehydration>      </Configuration></xlangs>
Para determinar a instância de sistema anfitrião está a ser executado o orchestration, poderá fazer corresponder o ID de processo o processo de \BizTalk:Messaging\ID e \Process\ID os contadores do Monitor de desempenho do processo. Em seguida, verifique o valor médio apresentado para o correspondente \Process\Virtual Bytes e \Process\Private os contadores do Monitor de desempenho de Bytes.

Nota A desidratação elevada poderá provocar uma diminuição significativa no desempenho quando a base de dados do BizTalkMsgBoxDb está em execução no SQL Server 2008.

Servidor BizTalk Service Packs e actualizações cumulativas

BizTalk Server service packs e actualizações cumulativas incluem as correcções mais recentes. Estas incluem as que afectam a problemas conhecidos de System.OutOfMemoryException.

2281783 Lista de Service Pack e de actualização cumulativa para o BizTalk Server 2006 R2

Microsoft BizTalk Server 2004 Service Pack 2

HeapDeCommitFreeBlockThreshold

Por predefinição, o valor de chave de registo theHeapDeCommitFreeBlockThreshold é 0. Um valor de 0 significa que o Gestor da área para dados dinâmicos decommits cada página do 4 quilobytes (KB) que fica disponível. Anular operações podem provocar a fragmentação da memória virtual. O tamanho da definição HeapDeCommitFreeBlockThreshold no Gestor de área dinâmica para dados depende do tipo de trabalho que o sistema está a fazer. Um tamanho de 0x00040000 é um valor inicial recomendado.

Considere as seguintes informações antes de alterar o valor da
HeapDeCommitFreeBlockThreshold
chave do registo:
  • Esta alteração só se aplica a fragmentationproblems de memória.
  • Esta alteração é ao nível do sistema. Por conseguinte, mais processos willuse mais de memória no arranque.
  • Considere apenas esta alteração em sistemas que tenham BizTalkServer como a sua missão primário.
Para ajudar a reduzir a fragmentação da memória virtual, pode aumentar o tamanho da definição HeapDeCommitFreeBlockThreshold no Gestor de área dinâmica para dados alterando o valor da seguinte chave de registo:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager


Nome do valor: HeapDeCommitFreeBlockThreshold
Tipo de valor: REG_DWORD
Dados do valor: 0x00040000 (este é o valor inicial recomendado.)
Valor predefinido: não apresentar
Para mais informações sobre a chave de registo HeapDeCommitFreeBlockThreshold, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
315407 A chave de registo "HeapDecommitFreeBlockThreshold"

Operações de transformação

Quando o BizTalk Server efectua operações de transformação XML em mensagens bastante grandes num porto de recepção, uma porta de envio, ou na XLANG, o XSL transforma carregar a mensagem completa na memória...

Para resolver este problema, utilize um dos seguintes métodos:
  • Diminua o número de mensagens que Serverprocesses de BizTalk ao mesmo tempo.
  • Reduza o tamanho da mensagem XML que é beingtransformed.
O objecto System.Policy.Security.Evidence é frequentemente utilizado em transformações e pode consumir a quantidade de memória. Quando um mapa contém um functoid de script que utiliza inline c# (ou qualquer outro idioma inline), a assemblagem é criada na memória. O objecto System.Policy.Security.Evidence utiliza o objecto da assemblagem de chamada real. Esta situação cria um objecto enxertos que não é eliminado até que o serviço de BizTalk for reiniciado.

A maior parte das functoids de BizTalk predefinido é implementados como inline script. Estes itens podem causar System. byte [] objectos recolher na memória. Para minimizar o consumo de memória, recomendamos que coloque um mapa que utiliza estes functoids numa assemblagem pequena. Em seguida, fazer referência a essa assemblagem. Utilize o gráfico seguinte para determinar que functoids utilizar inline script e que functoids não utilizar o inline script.

Na segunda coluna, "Sim" significa que este functoid é implementada como inline script, e que causará a System. byte [] objectos recolher na memória. "Não" significa que este functoid não está implementado como inline script e que não origine System. byte [] objectos recolher na memória.
FunctoidsScript incorporado?
Todos os Functoids de cadeiaSim
Todos os Functoids de matemáticasSim
Todos os Functoids lógicos, excepto IsNilSim
Lógica IsNil FunctoidNão
Todos os Functoids de data/horaSim
Todos os Functoids de conversãoSim
Todos os Functoids científicosSim
Todos os Functoids cumulativasSim
Todos os Functoids de base de dadosNão
Functoids avançadasScript incorporado?
Functoid loopNão
Valor mapeamento aplanar FunctoidNão
Functoid de asserçãoNão
Tabela Extractor FunctoidNão
Functoid de ciclo de tabelaNão
Functoid de processamento de scripts com Inline c#Sim
Functoid de processamento de scripts com Inline de JScript.NETSim
Functoid com .NET Inline Visual de base de processamento de scriptsSim
Functoid de processamento de scripts com o Inline XSLTNão
Functoid de processamento de scripts com o modelo de chamada Inline XSLTNão
Functoid script chamar assemblagem externoNão
Functoid de valor nuloNão
Valor de mapeamento de FunctoidNão
Functoid de cópia de massaNão
Functoid de iteraçãoNão
Índice FunctoidNão
Functoid de contagem de registosNão
BizTalk Server 2006 e versões posteriores melhorar significativamente a gestão da memória para documentos grandes. Para efectuar este procedimento, o BizTalk Server implementa um limite de tamanho de mensagem configurável para carregar documentos para a memória durante as operações de transformação. O limite do tamanho da mensagem predefinido é 1 MB. Para mais informações sobre a definição de TransformThreshold, visite o seguinte Web site da Microsoft Developer Network (MSDN):

Valores de atributo de grandes dimensões e valores de elemento de grandes dimensões

Quando o BizTalk Server executa uma tubagem de receber ou de uma tubagem enviar num documento XML, o payload é processado na memória, se o documento contém um ou mais das seguintes entidades:
  • Valores de atributo grande
  • Valores de elemento de grandes dimensões
  • Códigos de elemento ou atributo grandes
Para resolver este problema, limite o tamanho destas entidades. Se este método não for possível, certifique-se de que a instância de sistema anfitrião do BizTalk não processar vários documentos como estas ao mesmo tempo.

Componentes de tubagens personalizado

Está a utilizar um componente de tubagem personalizado que carrega a sequência completa para a memória. Todos os componentes que estão incluídos no BizTalk Server, excepto as transformações, suportam a transmissão em sequência. Estes componentes não utilizem o máximo de memória durante a transmissão em sequência. No entanto, componentes de tubagens personalizadas podem não suportar transmissão em sequência.

Transmissão em sequência em grande carga de trabalho

Envie anfitriões ficou sem memória que operem sob tensão pesado. BizTalk Server enviar tubagens e enviar a transmissão em sequência de suporte de placas. Na transmissão em sequência, cada componente carrega um pequeno fragmento da sequência na memória. Uma vez que cada mensagem inclui outras estruturas de dados, bem como um contexto de mensagem que pode ser grande ou pequena, este comportamento afecta o comportamento do BizTalk Server sob tensão pesado.

O comportamento do BizTalk Server é afectado porque o motor carrega um número de mensagens pré-configurado. O número de mensagens que carrega o motor baseia-se os valores que aparecem no campo LowWaterMark e o campo HighWaterMark da tabela Adm_serviceClass. A tabela de Adm_serviceClass é a base de dados de Gestão BizTalk. Estes valores de controlam o número de mensagens BizTalk Server processa ou envia ao mesmo tempo.

O valor de HighWaterMark é o número total de mensagens que o motor processa ao mesmo tempo. O valor predefinido é de 200 mensagens por CPU. Por conseguinte, num servidor de processador 8, o anfitrião de envio irá tentar processar mensagens 1 600 (200 * 8), ao mesmo tempo. Se assumir que cada mensagem é 50 KB, as mensagens igual a 80 MB (1, 600 * 50 = 80 000KB).

Para resolver este problema, pode alterar o valor de HighWaterMark e o valor de LowWaterMark na base de dados. Os valores que utilizar dependem do tamanho das mensagens.

Para mais informações sobre causas comuns de uma condição de memória esgotada, consulte a secção "Memória crescimento no BizTalk Messaging" no seguinte Web site da Microsoft:Para o BizTalk Server 2006 e versões posteriores, pode alterar o anfitrião predefinido às definições de optimização. Para mais informações sobre como alterar o anfitrião predefinido às definições de optimização, visite o seguinte Web site da Microsoft Developer Network (MSDN):

Tente simplificar o problema

Se identificou uma fuga de memória, tente determinar a causa pela remoção de componentes personalizados ou simplificar um mapa. Além disso, tente reproduzir o problema utilizando um orchestration simple ou uma solução simples. Normalmente, deve criar separado receber anfitriões para recebem placas. Deverá criar também anfitriões de envio separadas para placas de envio. Quando utilizar este método, cada placa pode executar um processo separado. Por conseguinte, se o processo do servidor BizTalk uma condição de memória esgotada, ficará a saber quais os componentes envolvidos.

Passos de resolução de problemas

Para resolver uma condição de memória esgotada, utilize a ferramenta Debug Diagnostics para monitorizar as alocações de memória ao longo do tempo. A ferramenta Debug Diagnostics pode criar e analisar um ficheiro de informação de fuga de memória (. dmp). Quando resolver fugas de memória, o objectivo consiste em Anexar Leaktrack.dll antes da condição de memória alta reproduz para capturar o crescimento de memória ao longo do tempo. Leaktrack.dll, incluída com a ferramenta Debug Diagnostics.
  1. Instale a ferramenta de diagnóstico de depuração.

    O ficheiro seguinte está disponível para transferência a partir do Centro de transferências da Microsoft:

    TransferirTransferir o pacote da ferramenta de diagnóstico Debug. exe agora.

    Para mais informações sobre como transferir ficheiros de suporte da Microsoft, clique no número de artigo seguinte para visualizar o artigo na Base de Dados de Conhecimento Microsoft:
    119591 Como obter ficheiros de suporte da Microsoft a partir de serviços online
    A Microsoft analisou este ficheiro quanto à presença de virus. A Microsoft utilizou o software de deteção de vírus mais atual, que estava disponível na data em que o ficheiro foi publicado. O ficheiro está armazenado em servidores com segurança melhorada que ajudam a impedir alterações não autorizadas ao ficheiro.
  2. Utilize o Monitor de desempenho para recolher dados sobre systemperformance. Estes dados podem fornecer indicadores importantes sobre o ofyour de eficiência ambiente do servidor BizTalk. O objectivo consiste em capturar o tempo de performanceover do processo. Por conseguinte, Active o registo de Monitor de desempenho antes do leakoccurs de memória.

Como utilizar o registo do Monitor de desempenho

Seleccione os dados para iniciar sessão
Para seleccionar os dados para iniciar sessão, utilize o método adequado para o sistema operativo:
  • Para Windows Server 2008 e Windows Server 2008 R2
    1. Em Ferramentas administrativas, abra o Monitor de desempenho e fiabilidade.
    2. Monitor de desempenhocom o botão direito, clique em Novo e, em seguida, clique em Conjunto de Recolectores de dados.
    3. Na caixa nome , escreva um nome descritivo e, em seguida, clique em seguinte.
    4. Tenha em atenção o directório raiz e, em seguida, clique em seguinte.
    5. Clique em Iniciar este agora a conjunto de Recolectores de dadose, em seguida, clique em Concluir.
    6. Expanda Conjuntos de Recolectores de dados, expanda Definido pelo utilizador e, em seguida, seleccione o ficheiro.
    7. Registo do Monitor de sistemacom o botão direito e, em seguida, clique em Propriedades.
    8. Clique em Adicionar sobre o separador Contadores de desempenho seguintes objectos e, em seguida, clique em Adicionar depois de seleccionar cada objecto:
      • Excepções do .net CLR
      • Memória do .net CLR
      • BizTalk: mensagens
      • BizTalk:TDDS
      • Memória
      • Processo
      • Processador
      • Orchestrations XLANG/s
      Se o SQL Server for local, adicione também os seguintes objectos:
      • SQLServer:Databases
      • Estatísticas de SQLServer:General
      • Gestor de SQLServer:Memory
    9. Clique em OK.
    10. Altere a caixa de valor de intervalo de amostra para 5 segundos.

      Nota O valor do intervalo de amostra e a hora para começar a monitorizar são subjectivo. Estes valores dependem quando é reproduzida a fuga de memória. Uma vez que o ficheiro de registo pode ser grande, especificar um intervalo no qual pode obter as informações que tem de ter sem asfixiam o servidor.
    11. Clique em OK.
    Para parar a recolha de dados, clique em Parar no menu acção .
  • Para o Windows Server 2003 ou para o Windows XP
    1. Expanda os Alertas e registos de desempenho.
    2. Com o botão direito Registos de contadore, em seguida, clique em Novas definições do registo. É apresentada a caixa de diálogo Definições de registo novo .
    3. Na caixa nome , escreva um nome descritivo e, em seguida, clique em OK.
    4. Anote a localização do ficheiro de registo. (Pode também clicar no separador Ficheiros de registo e, em seguida, clique em Configurar para alterar a localização do ficheiro de registo.)
    5. Clique em Adicionar contadores.
    6. Seleccione todos os contadores e todas as instâncias.
    7. Na lista de objectos de desempenho , seleccione os seguintes objectos. Depois de seleccionar cada objecto, clique em Adicionar .
      • Excepções do .net CLR
      • Memória do .net CLR
      • BizTalk: mensagens
      • BizTalk:TDDS
      • Memória
      • Processo
      • Processador
      • Orchestrations XLANG/s
      Se o SQL Server for local, adicione também os seguintes objectos:
      • SQLServer:Databases
      • Estatísticas de SQLServer:General
      • Gestor de SQLServer:Memory
    8. Clique em Fechar.
    9. Altere o valor no Intervalo de amostragem de dados para 5 segundos.

      Nota O valor do intervalo de recolha de dados e a hora para começar a monitorizar são subjectivo. Estes valores dependem quando é reproduzida a fuga de memória. Uma vez que o ficheiro de registo pode ser grande, especificar um intervalo no qual pode obter as informações que tem de ter sem asfixiam o servidor.
    10. Clique em OK.
    Para parar a recolha de dados, com o botão direito no nome do registo de contador e, em seguida, clique em Parar.
Obter o ficheiro de informação
Para obter o ficheiro de informação, utilize um dos seguintes métodos:
  • Método 1: automático
    Criar uma regra de memória e fuga de lidar com DebugDiag é a abordagem recomendada para capturar informações de memória. A regra de memória e processar fuga anexa automaticamente Leaktrack.dll. É utilizado para controlar as alocações de memória. Para criar a regra de memória e processar fuga, siga estes passos:
    1. Inicie a ferramenta de diagnóstico de depuração 1.1.
    2. Seleccione a memória e processar fugae, em seguida, clique em seguinte.
    3. Seleccione o processo de Btsntsvc.exe e, em seguida, clique em seguinte.
    4. Na página configurar a regra de fuga, siga estes passos:
      1. Clique para seleccionar a caixa de verificação Iniciar rastreio imediatamente quando é activada a regra de memória . Caso contrário, pode especificar um tempo de aquecimento antes de LeakTrack.dll é injectada no processo de BTSNTSvc.exe.
      2. Clique em Configurare, em seguida, efectue o seguinte:
        • Confirmar que criar automaticamente uma regra de falha de sistema está seleccionada. Seleccionando esta opção, uma informação de memória será criada automaticamente se o processo de BTSNTSvc.exe pára.
        • Clique para seleccionar a caixa de verificação de gerar um userdump quando bytes do espaço virtuais alcançar e manter o valor predefinido de 1024.
        • Clique para seleccionar a caixa de verificação e cada adicionais e mantenha a predefinição de 200.
        Seleccionando os bytes virtuais chegar a opção, uma informação de memória será automaticamente criada quando bytes do espaço virtuais utiliza 1024 MB. Se os bytes de espaço virtuais aumenta em 200 MB, outra informação de memória será criada automaticamente.
      3. Clique em Guardar & fechar.
      4. Clique em seguinte.
    5. Na página seleccione Copiar localização e nome da regra, clique em seguinte.

      Nota Também pode alterar o caminho do ficheiro de informação na caixa Localização Userdump nesta página.
    6. Clique em Concluir para tornar a regra active agora.
    Nota Agora é controlar o estado de regra. Sempre que é criada uma cópia de memória, o valor para aumentar a coluna de contagem de Userdump no separador regras. A localização de cópia de memória predefinida é c:\Programas\Microsoft Files\DebugDiag\Logs.
  • Método 2: Manual
    Pode também anexar Leaktrack.dll e obter manualmente o ficheiro de informação de memória. Isto permite-lhe controlo quando o estado da memória é criado. Para tal, siga estes passos:
    1. Inicie a ferramenta de diagnóstico de depuração 1.1.
    2. Clique no separador processos .
    3. O processo de Btsntsvc.exe com o botão direito e, em seguida, faça clique sobre o Monitor de fugas.
    4. Na caixa de diálogo Ferramenta Debug Diagnostics , clique em Sime, em seguida, clique em OK.
    Crie uma regra de falha de sistema para monitorizar o mesmo processo de Btsntsvc.exe, no caso do processo pára antes de poder criar a informação de memória:
    1. Inicie a ferramenta de diagnóstico de depuração 1.1.
    2. Seleccione a falhare, em seguida, clique em seguinte.
    3. Seleccione um processo específicoe, em seguida, clique em seguinte.
    4. Seleccione o mesmo processo de Btsntsvc.exe e, em seguida, clique em seguinte.
    5. Na página Configuração avançada (opcional) , clique em seguinte.
    6. Na caixa de diálogo Seleccione Copiar localização e nome da regra (opcional) , clique em seguinte.
    7. Seleccione Activar agora a regrae, em seguida, clique em ' Concluir '.
    Quando o processo de atingir 60 a 80 por cento de RAM, o processo de Btsntsvc.exe com o botão direito e, em seguida, clique em Create Full Userdump. Se o processo de BizTalk pára antes de poder criar a informação de estado do utilizador, a regra falha deve entrem em vigor e crie o estado da memória.
Parar o registo do Monitor de desempenho
Se estiver a capturar uma informação de memória e os dados do Monitor de desempenho, deixar de cerca de dois minutos depois de criada a informação de memória de registo do Monitor de desempenho.
Analisar o ficheiro de informação
Para ajudar a determinar a causa de uma fuga de memória, pode utilizar a ferramenta Debug Diagnostics para analisar o ficheiro de informação. Para tal, siga estes passos:
  1. Clique no separador Advanced Analysis.
  2. Clique em Adicionar ficheiros de dadose, em seguida, localize o ficheiro the.dmp.
  3. Seleccione o script de Análise de pressão de memóriae, em seguida, clique em Iniciar análise.
Por predefinição, um ficheiro de mapa de análise (. mht) será criado na pasta C:\Program Files\DebugDiag\Reports quando a análise estiver concluída. O ficheiro de relatório serão também apresentado no browser. O ficheiro de relatório contém os resultados da análise. Além disso, o ficheiro de relatório pode incluir recomendações como resolver a fuga de memória.

Se utilizar DLLs personalizadas, pode adicionar o caminho de símbolos dos ficheiros. pdb personalizados para análise. Para tal, siga estes passos:
  1. Abra a ferramenta Debug Diagnostics.
  2. No menu Ferramentas , clique em Definições de Optionsand.
  3. Na caixa Símbolo procura caminho para a depuração, escreva o caminho de símbolos.
Se pretender analisar o ficheiro de informação de ajuda, contacte o suporte técnico da Microsoft. Para obter uma lista completa dos números de telefone do suporte técnico e informações sobre os custos de suporte, visite o seguinte Web site da Microsoft: Antes de contactar o suporte técnico, comprima o ficheiro de informação, o registo do Monitor de desempenho, o ficheiro de mapa de análise e os registos de eventos actualizados (ficheiros. evt). Poderá ter de enviar que esses ficheiros para um servidor de BizTalk engenheiro de suporte.

Propriedades

ID do Artigo: 918643 - Última Revisão: 10/29/2015 00:35:00 - Revisão: 3.0

Microsoft BizTalk Server Branch 2010, Microsoft BizTalk Server Developer 2010, Microsoft BizTalk Server Enterprise 2010, Microsoft BizTalk Server Standard 2010, Microsoft BizTalk Server 2009 Branch, Microsoft BizTalk Server 2009 Developer, Microsoft BizTalk Server 2009 Enterprise, Microsoft BizTalk Server 2009 Standard, Microsoft BizTalk Server 2006 R2 Branch, Microsoft BizTalk Server 2006 R2 Developer Edition, Microsoft BizTalk Server 2006 R2 Enterprise Edition, Microsoft BizTalk Server 2006 R2 Standard Edition, Microsoft BizTalk Server 2006 Enterprise Edition, Microsoft BizTalk Server 2006 Developer Edition, Microsoft BizTalk Server 2006 Standard Edition, Microsoft BizTalk Server 2004 Enterprise Edition, Microsoft BizTalk Server 2004 Developer Edition, Microsoft BizTalk Server 2004 Partner Edition, Microsoft BizTalk Server 2004 Standard Edition

  • kbhowto kbmt KB918643 KbMtpt
Comentários