Como solucionar problemas de um vazamento de memória ou uma exceção fora de memória no processo de BizTalk Server

Este artigo descreve como solucionar problemas de um vazamento de memória ou uma exceção fora da memória no processo BizTalk Server do Microsoft BizTalk Server.

Versão original do produto: BizTalk Server 2010, 2009
Número de KB original: 918643

Resumo

Vazamentos de memória são um problema comum. Talvez você precise tentar várias etapas para encontrar a causa específica de um vazamento de memória ou uma exceção de OOM (fora de memória) no Microsoft BizTalk Server. Este artigo discute coisas importantes a serem consideradas quando você avalia o uso da memória e possíveis problemas relacionados à memória. Essas considerações incluem as seguintes coisas:

  • RAM física
  • Processamento de mensagens grandes
  • Uso da opção /3GB
  • Uso de componentes personalizados
  • Qual versão do Microsoft .NET Framework o sistema está em execução
  • O número de processadores

O processo BizTalk Server pode estar enfrentando um vazamento de memória quando o uso de memória no Gerenciador de Tarefas do Microsoft Windows consome mais de 50% da RAM física. Um vazamento de memória pode causar uma exceção fora da memória quando o uso de memória aumenta até que o processo esteja sem memória do sistema ou até que o processo pare de funcionar. Para este problema, considere o seguinte:

Uso de memória e RAM física

Como pode ser um comportamento esperado para um processo usar cerca de metade da RAM física, use o uso de memória como diretriz. Por exemplo, se o BizTalk Server tiver 4 gigabytes (GB) de RAM e o processo BizTalk Server usar cerca de 500 megabytes (MB) de RAM, talvez não haja vazamento. Se o processo BizTalk Server usar cerca de 1 GB de RAM, poderá haver um vazamento de memória ou uma situação de memória alta. O consumo de memória pode ser causado por um procedimento armazenado de longa duração ou orquestração. Verifique se você sabe quanta memória o host BizTalk normalmente usa para determinar se um vazamento de memória ou uma condição de memória alta está ocorrendo.

Mensagens grandes

Quando BizTalk Server processa mensagens grandes, o sistema parece ter um vazamento de memória. No entanto, as mensagens podem estar usando uma grande quantidade de memória.

Além disso, considere que o alto uso de memória pode ser esperado se BizTalk Server estiver processando mensagens grandes. Talvez você queira atualizar seu hardware para atender aos requisitos de desempenho de BizTalk Server em seu ambiente.

Quanto tempo leva para reproduzir o vazamento de memória

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

Uso da opção /3GB em computadores de 32 bits

Normalmente, um processo pode acessar 2 GB de espaço de endereço virtual. A opção /3GB é uma opção para sistemas que exigem memória mais endereçável. Essa opção pode melhorar o uso de memória para processamento de mensagens. No entanto, o comutador de /3 GB permite apenas 1 GB de memória endereçável para operações do modo kernel. Além disso, essa opção pode aumentar o risco de ficar sem memória do pool.

Quando o comutador de /3 GB está habilitado em uma versão de 32 bits do Windows, o processo pode acessar 3 GB de espaço de endereço virtual se o processo estiver ciente de endereço grande. Um processo é de grande reconhecimento de endereço quando o executável tem o sinalizador IMAGE_FILE_LARGE_ADDRESS_AWARE definido no cabeçalho da imagem. Como o processo BizTalk está ciente de endereço grande, o BizTalk se beneficiará da opção /3 GB.

Se uma instância de host BizTalk de 32 bits estiver em execução em uma versão de 64 bits do Windows (AMD64), o processo BizTalk se beneficiará do espaço de endereço de memória de 4 GB porque o BizTalk está ciente de endereço grande. Portanto, mover seus aplicativos de memória alta para um servidor de 64 bits pode ser a melhor solução.

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

Você também deve considerar os bytes virtuais e os bytes privados usados pelo processo. Uma instância de host BizTalk (que é um aplicativo .NET Framework) pode receber um erro de memória fora da memória antes que o valor de Bytes Virtuais atinja 2 GB. Essa situação pode ocorrer mesmo que o máximo de memória endereçável por um processo em uma versão de 32 bits do Windows (sem o comutador de /3 GB) seja de 2 GB. Para obter uma explicação de por que essa situação pode ocorrer, visite o seguinte site da MSDN (Microsoft Developer Network):
ASP.NET Monitoramento de Desempenho e Quando Alertar Administradores

A opção /3GB também aumenta os bytes privados máximos do processo BizTalk de 800 MB para 1800 MB. Para obter mais informações sobre .NET Framework desempenho do aplicativo com o comutador de /3 GB habilitado, visite Capítulo 17– Ajuste do desempenho do aplicativo .NET.

A tabela a seguir resume essas informações e inclui os limites práticos para bytes virtuais e bytes privados.

Processo Windows Memória endereçável (com um grande processo de reconhecimento de endereço) Limite prático para bytes virtuais Limite prático para bytes privados
32 bits 32 bits 2 GB 1400 MB 800 MB
32 bits 32 bits com /3GB 3 GB 2400 MB 1800 MB
32 bits 64 bits 4 GB 3400 MB 2800 MB
64 bits 64 bits 8 TB Não aplicável Não aplicável

Para obter mais informações sobre a memória endereçável para Windows de 32 bits versus 64 bits, visite Limites de Memória para Versões do Windows e do Windows Server.

A tabela a seguir lista a pae e a capacidade de suporte de 3 GB para diferentes versões de BizTalk Server.

Produto PAE 3 GB
BizTalk Server 2004 Sim Não
BizTalk Server 2006 Sim Sim
BizTalk Server 2006 R2 Sim Sim
BizTalk Server 2009 Sim Sim

Se você precisar habilitar a opção /3GB para atender aos requisitos de desempenho de um computador que está executando BizTalk Server, talvez você queira considerar a adição de servidores ao grupo BizTalk. Isso permite dimensionar as instâncias de host com uso intensivo de memória.

Os componentes biztalk executados dentro de um processo do IIS (Serviços de Informações da Internet) também podem se beneficiar quando a opção /3GB estiver habilitada.

O comutador de /3 GB não tem suporte em computadores que estão executando Windows SharePoint Services versões 2.0 ou posteriores ou SharePoint Portal Server versões 2003 SP2 ou posteriores. O comutador do Windows Server 2003 /3GB não tem suporte em Windows SharePoint Services 2.0 ou em versões posteriores ou em SharePoint Portal Server 2003 Service Pack 2 ou em versões posteriores.

Uso de componentes personalizados

Se você usar componentes personalizados, como pipelines ou componentes de serviço, deverá saber o que esses componentes fazem. Você também deve saber o efeito potencial desses componentes no uso da memória. Um problema de memória comum ocorre quando um componente está transformando um documento. A operação de transformação é uma operação com uso intensivo de memória. Quando um documento é transformado, BizTalk Server passa o fluxo de mensagens para a classe microsoft .NET Framework XslTransform no processo BizTalk.

Outro problema comum ocorre quando há manipulação intensiva de cadeia de caracteres. A manipulação intensiva de cadeia de caracteres pode consumir muitas memórias. Para obter mais informações sobre maneiras de melhorar o desempenho, visite Aprimorando o desempenho do código gerenciado.

Versão do .NET Framework

O Microsoft .NET Framework 2.0 e o .NET Framework 1.1 têm um comportamento de memória diferente. Portanto, você pode ver resultados variados entre eles. Se você estiver usando o .NET Framework, confirme se o mais recente .NET Framework Service Pack 1 está instalado. Esses pacotes de serviço resolvem vários problemas de memória conhecidos.

Número de processadores

O CLR (common language runtime) tem os seguintes coletores de lixo (GCs):

  • Estação de trabalho (Mscorwks.dll)
  • Servidor (Mscorsvr.dll)

Se o computador que está executando BizTalk Server for um sistema multiprocessador, o .NET Framework usará a versão server do mecanismo de execução. Esse é o comportamento padrão. O coletor de lixo do Servidor foi projetado para a taxa de transferência máxima. Além disso, o coletor de lixo do Servidor é dimensionado para fornecer alto desempenho. Esse coletor de lixo aloca memória e, em seguida, libera memória para fornecer alto desempenho no sistema. Portanto, um computador que está executando BizTalk Server junto com alguns componentes .NET Framework parece ter um vazamento de memória. No entanto, nesse cenário, o alto uso de memória é o comportamento esperado. Se o computador ficar sem memória do sistema ou se o processo parar de funcionar devido à memória endereçável insuficiente, poderá existir uma condição de vazamento de memória.

Se o computador que está executando BizTalk Server for um único sistema de processador, o .NET Framework usará a versão workstation do mecanismo de execução. É o comportamento padrão. O algoritmo de alocação do coletor de lixo da estação de trabalho não foi projetado para dimensionamento ou para taxa de transferência máxima. Esse coletor de lixo usa métodos simultâneos de coletor de lixo. Esses métodos são projetados para aplicativos que têm interfaces de usuário complexas. Esses aplicativos podem exigir coleta de lixo mais agressiva.

Importante

Esta seção, método ou tarefa contém etapas que descrevem como modificar o Registro. Mas problemas graves podem ocorrer se você modificar o registro incorretamente. Portanto, certifique-se de seguir essas etapas com cuidado. Para mais proteção, faça o backup do registro antes de modificá-lo. Em seguida, você poderá restaurar o registro se ocorrer um problema. Para saber mais sobre como fazer o backup e restaurar o registro, consulte Como fazer o backup e restaurar o registro no Windows.

Às vezes, pode ser apropriado executar a versão workstation do mecanismo de execução em um sistema multiprocessador. Você pode usar a chave do registro a seguir para alternar para a versão workstation do mecanismo de execução.

BizTalk 2006 e versões posteriores

Create o seguinte CRL Hosting Chave de registro de cadeia de caracteres com os valores correspondentes:

  • Chave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • Nome do valor: Sabor
  • Dados de valor: wks

BizTalk 2004

Create o seguinte CRL Host Chave de registro de cadeia de caracteres com os valores correspondentes:

  • Chave: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • Nome do valor: Sabor
  • Dados de valor: wks

Para obter mais informações, visite Considerações de desempenho para tecnologias de Run-Time no .NET Framework.

A seguir estão causas e resoluções comuns:

Limites de limitação de uso de memória física e processo

Os limites de limitação de uso de memória física e uso de memória física podem ser alterados em BizTalk Server 2006 e em versões posteriores.

  • Por padrão, o limite de limitação de uso de memória de processo é definido como 25. Se esse valor for excedido e o uso de memória do processo BizTalk for superior a 300 MB, poderá ocorrer uma condição de limitação. Em um servidor de 32 bits, você pode aumentar o valor de uso de memória de processo para 50. Em um servidor de 64 bits, você pode aumentar esse valor para 100. Isso permite mais consumo de memória pelo processo BizTalk antes da limitação ocorrer.

  • O limite de limitação de uso de memória física tem um valor padrão de 0. Esse limite mede a memória total do sistema. Portanto, se um valor diferente de 0 estiver configurado, uma condição de limitação poderá ocorrer se um processo não BizTalk estiver usando memória alta.

Limites de limitação de desidratação

Os limites de desidratação de memória padrão podem causar muita desidratação quando as orquestrações são executadas em um host de 64 bits. Para obter mais informações sobre esse problema, consulte Propriedades Padrão de Desidratação.

Observação

Há suporte para hosts de 64 bits em versões BizTalk Server 2006 e posteriores.

Em hardware equivalente em uma instância de host de 32 bits, a desidratação observada é nominal quando as mesmas orquestrações são executadas usando os limites de limitação de desidratação de memória padrão.

Como a arquitetura de 64 bits fornece espaço de endereço de memória expandido (16 TB em vez de 4 GB), as instâncias de host de 64 bits são alocadas mais memória do que instâncias de host de 32 bits. Isso pode fazer com que os limites de limitação de memória padrão sejam excedidos.

Para contornar esse comportamento, altere os valores VirtualMemoryThrottlingCriteria e PrivateMemoryThrottlingCriteria no arquivo BTSNTSvc64.exe.config. Use os contadores \Process\Virtual Bytes e \Process\Private Bytes Monitor de Desempenho para determinar a maior quantidade de memória que está sendo alocada por uma instância de orquestração.

  • Defina o valor IdealUsage para ambas as propriedades com base no seguinte:

    • VirtualMemoryThrottlingCriteria: \Process\Virtual Bytes value + 10%
    • PrivateMemoryThrottlingCriteria: \Process\Private Bytes value + 10%
  • Defina MaximalUsage para ambas as propriedades como o valor IdealUsage + 30%

Por exemplo, se o valor do contador \Process\Virtual Byte Monitor de Desempenho para uma instância de orquestração for 5.784.787.695 bytes (5.517 MB), defina o valor IdealUsage para VirtualMemoryThrottlingCriteria a 6.069 MB (5.784.787.695 * 1,10 = 6.363.266.464,5 bytes).

Defina o valor MaximalUsage para VirtualMemoryThrottlingCriteria como 7.889 MB (6.363.266.464,5 * 1,30 = 8.272.246.403,85 bytes).

Se o valor do contador \Process\Private Bytes Monitor de Desempenho for 435689400 bytes (415 MB), defina o valor OptimalUsage para PrivateMemoryThrottlingCriteria como 457 MB (435689400 * 1,10 = 479258340 bytes).

Defina o valor MaximalUsage para PrivateMemoryThrottlingCriteria como 594 MB (479258340 * 1,30 = 623035842).

Para este exemplo, os valores a seguir seriam especificados no arquivo BTSNTSvc64.exe.config para reduzir a limitação.

contador Monitor de Desempenho Memória alocada OptimalUsage MaximalUsage
\Process\Bytes virtuais 5.784.787.695 bytes (5517 MB) 6069 7889
\Process\Bytes privados 435.689.400 bytes (415 MB) 457 594

Esses valores seriam representados no arquivo BTSNTSvc64.exe.config da seguinte maneira:

<xlangs>
    <Configuration>
       <Dehydration>
         <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
         <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
       </Dehydration>
    </Configuration>
</xlangs>

Para determinar qual instância de host está executando a orquestração, você pode corresponder ao Processo de ID dos contadores \BizTalk: Processo de Mensagens\ID e \Process\ID Process Monitor de Desempenho. Em seguida, marcar o valor médio exibido para os contadores \Process\Virtual Bytes e \Process\Private Bytes Monitor de Desempenho.

Observação

Informações que o usuário deve observar mesmo que a desidratação alta possa causar uma redução significativa no desempenho quando o BizTalkMsgBoxDb banco de dados estiver em execução no SQL Server 2008.

BizTalk Server pacotes de serviço e atualizações cumulativas

BizTalk Server pacotes de serviço e atualizações cumulativas incluem as correções mais recentes. Isso inclui aqueles que afetam problemas conhecidos System.OutOfMemoryException .

HeapDeCommitFreeBlockThreshold

Por padrão, o valor da chave do HeapDeCommitFreeBlockThreshold registro é 0. Um valor de 0 significa que o gerenciador de heap descompõe cada página de 4 quilobytes (KB) que se torna disponível. Operações de despromissão podem causar fragmentação de memória virtual. O tamanho da HeapDeCommitFreeBlockThreshold configuração no gerenciador de heap dependerá do tipo de trabalho que o sistema está fazendo. Um tamanho de 0x00040000 é um valor inicial recomendado.

Considere as seguintes informações antes de alterar o valor da chave do HeapDeCommitFreeBlockThreshold registro:

  • Essa alteração só se aplica a problemas de fragmentação de memória.
  • Essa alteração é em todo o sistema. Portanto, a maioria dos processos usará mais memória na inicialização.
  • Considere apenas essa alteração para sistemas que têm BizTalk Server como sua missão primária.

Para ajudar a reduzir a fragmentação de memória virtual, você pode aumentar o tamanho da HeapDeCommitFreeBlockThreshold configuração no gerenciador de heap alterando o valor da seguinte chave do registro em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager:

  • Nome do valor: HeapDeCommitFreeBlockThreshold
  • Tipo de valor: REG_DWORD
  • Dados de valor: 0x00040000 (é o valor inicial recomendado.)
  • Padrão de valor: não está presente

Transformar operações

Quando BizTalk Server executa operações de transformação XML em mensagens bastante grandes em uma porta de recebimento, em uma porta de envio ou em XLANG, o XSL transforma carregar toda a mensagem na memória.

Para resolver esse problema, use um dos seguintes métodos:

  • Reduza o número de mensagens que BizTalk Server processos ao mesmo tempo.
  • Reduza o tamanho da mensagem XML que está sendo transformada.

O System.Policy.Security.Evidence objeto é usado com frequência em transformações e pode consumir muita memória. Quando um mapa contém um script functoid que usa C# embutido (ou qualquer outra linguagem embutida), o assembly é criado na memória. O System.Policy.Security.Evidence objeto usa o objeto do assembly de chamada real. Essa situação cria um objeto enraizado que não é excluído até que o serviço BizTalk seja reiniciado.

A maior parte do BizTalk functoids padrão é implementada como script embutido. Esses itens podem fazer com que System.Byte[] objetos sejam coletados na memória. Para minimizar o consumo de memória, recomendamos que você coloque qualquer mapa que os functoids use em um pequeno assembly. Em seguida, referencie esse assembly. Use o gráfico a seguir para determinar qual functoids script embutido e quais functoids não usam script embutido.

Na segunda coluna, Sim significa que isso functoid é implementado como script embutido e que fará com System.Byte[] que objetos sejam coletados na memória. Não significa que isso functoid não seja implementado como script embutido e que não fará com System.Byte[] que objetos sejam coletados na memória.

Functoids Script embutido?
Todos os Functoids de cadeia de caracteres Sim
Todos os Functoids Matemáticos Sim
Todos os Functoids lógicos, exceto IsNil Sim
Functoid isnil lógico Não
Todos os Functoids de data/hora Sim
Todos os Functoids de Conversão Sim
Todos os Functoids Científicos Sim
Todos os Functoids Cumulativos Sim
Todos os Functoids de Banco de Dados Não
Functoids avançados Script embutido?
Looping Functoid Não
Functoid de nivelamento Value-Mapping Não
Assert Functoid Não
Functoid do Extrator de Tabela Não
Functoid de loop de tabela Não
Scripting Functoid with Inline C# Sim
Scripting Functoid with Inline JScript.NET Sim
Scripting Functoid with Inline Visual Basic .NET Sim
Scripting Functoid with Inline XSLT Não
Scripting Functoid with Inline XSLT Call Template Não
Scripting Functoid chamando Assembly Externo Não
Functoid de Valor Zero Não
Functoid de Mapeamento de Valor Não
Functoid de cópia em massa Não
Iteração Functoid Não
Index Functoid Não
Contagem de registros Functoid Não

BizTalk Server versões 2006 e posteriores melhoram significativamente o gerenciamento de memória para documentos grandes. Para fazer isso, BizTalk Server implementa um limite de tamanho de mensagem configurável para carregar documentos na memória durante as operações de transformação. O limite de tamanho da mensagem padrão é de 1 MB. Para obter mais informações sobre a configuração TransformThreshold, visite Como BizTalk Server processa mensagens grandes.

Valores de atributo grandes e valores de elementos grandes

Quando BizTalk Server executa um pipeline de recebimento ou um pipeline de envio em um documento XML, a carga será processada na memória se o documento contiver uma ou mais das seguintes entidades:

  • Valores de atributo grandes
  • Valores de elementos grandes
  • Marcas de atributo ou elemento grandes

Para resolve esse problema, limite o tamanho dessas entidades. Se esse método não for possível, verifique se a instância host do BizTalk não processa vários documentos como esses ao mesmo tempo.

Componentes de pipeline personalizados

Você está usando um componente de pipeline personalizado que carrega todo o fluxo na memória. Todos os componentes incluídos com BizTalk Server, exceto transformações, dão suporte ao streaming. Esses componentes não usam tanta memória durante o streaming. No entanto, os componentes de pipeline personalizados podem não dar suporte ao streaming.

Streaming sob forte estresse

Enviar hosts sem memória quando eles operam sob forte estresse. BizTalk Server envia pipelines e envia aos adaptadores suporte a streaming. No streaming, cada componente carrega um pequeno fragmento do fluxo na memória. Como cada mensagem inclui outras estruturas de dados, juntamente com um contexto de mensagem que pode ser significativo ou pequeno, esse comportamento afeta o comportamento de BizTalk Server sob forte estresse.

O comportamento de BizTalk Server é afetado porque o mecanismo carrega um número pré-configurado de mensagens. O número de mensagens que o mecanismo carrega baseia-se nos valores que aparecem no campo LowWaterMark e no campo HighWaterMark da Adm_serviceClass tabela. A Adm_serviceClass tabela está no Banco de Dados de Gerenciamento biztalk. Esses valores controlam o número de mensagens que BizTalk Server processos ou envia ao mesmo tempo.

O valor HighWaterMark é o número total de mensagens que o mecanismo processa ao mesmo tempo. O valor padrão é 200 mensagens por CPU. Portanto, em um servidor de 8 processadores, o host de envio tentará processar 1.600 mensagens (200 * 8) ao mesmo tempo.

Se você pressupõe que cada mensagem seja de 50 KB, as mensagens serão iguais a 80 MB (1.600 * 50=80.000 KB).

Para resolve esse problema, você pode alterar o valor HighWaterMark e o valor LowWaterMark no banco de dados. Os valores usados dependem do tamanho das mensagens. Para versões BizTalk Server 2006 e posteriores, você pode alterar as configurações de limitação de host padrão.

Tente simplificar o problema

Se você identificou um vazamento de memória, tente determinar a causa removendo componentes personalizados ou simplificando um mapa. Além disso, tente reproduzir o problema usando uma orquestração simples ou uma solução simples. Normalmente, você deve criar hosts de recebimento separados para adaptadores de recebimento. Você também deve criar hosts de envio separados para adaptadores de envio. Quando você usa esse método, cada adaptador pode ser executado em um processo separado. Portanto, se o processo BizTalk Server tiver uma condição fora da memória, você saberá quais componentes estão envolvidos.

Etapas para a solução de problemas

Para solucionar problemas de uma condição fora da memória, use a ferramenta Diagnóstico de Depuração para monitorar alocações de memória ao longo do tempo. A ferramenta Depurar Diagnóstico pode criar e analisar um arquivo de despejo de vazamento de memória (.dmp). Quando você soluciona problemas de vazamentos de memória, o objetivo é anexar Leaktrack.dll antes que a alta condição de memória se reproduza para capturar o crescimento da memória ao longo do tempo. Leaktrack.dll está incluído na ferramenta Depurar Diagnóstico.

  1. Instale a Ferramenta de Diagnóstico de Depuração.

    O arquivo a seguir está disponível para download no Centro de Download da Microsoft:
    Baixar o pacote Depurar Ferramenta de Diagnóstico agora

    Para obter mais informações sobre como baixar arquivos de suporte da Microsoft, consulte Como obter arquivos de suporte da Microsoft de serviços online.

    A Microsoft examinou esse arquivo em busca de vírus. A Microsoft usou o software de detecção de vírus mais atual que estava disponível na data em que o arquivo foi postado. O arquivo é armazenado em servidores aprimorados pela segurança que ajudam a evitar alterações não autorizadas no arquivo.

  2. Use Monitor de Desempenho para coletar dados sobre o desempenho do sistema. Esses dados podem fornecer indicadores importantes sobre a eficiência do seu ambiente BizTalk Server. O objetivo é capturar o desempenho do processo ao longo do tempo. Portanto, habilite Monitor de Desempenho registro em log antes que o vazamento de memória ocorra.

Como usar o registro em log Monitor de Desempenho

As seções a seguir descrevem como usar o registro em log do monitor de desempenho.

Selecione os dados para fazer log

Para selecionar os dados para fazer log, use o método apropriado para seu sistema operacional:

  • Para Windows Server 2008 e Windows Server 2008 R2
    1. Em Ferramentas Administrativas, abra Confiabilidade e Monitor de Desempenho.

    2. Clique com o botão direito do mouse em Monitor de Desempenho, clique em Novo e clique em Conjunto de Coletor de Dados.

    3. Na caixa Nome , digite um nome descritivo e clique em Avançar.

    4. Observe o diretório Raiz e clique em Avançar.

    5. Clique em Iniciar esse conjunto de coletores de dados agora e clique em Concluir.

    6. Expanda Conjuntos de Coletores de Dados, expanda Definidos pelo Usuário e selecione seu arquivo.

    7. Clique com o botão direito do mouse em Log do Monitor do Sistema e clique em Propriedades.

    8. Clique em Adicionar na guia Contadores de Desempenho . Selecione os seguintes objetos e clique em Adicionar depois de selecionar cada objeto:

      • Exceções do .Net CLR
      • Memória CLR do .Net
      • BizTalk: Mensagens
      • BizTalk: TDDS
      • Memória
      • Processo
      • Processador
      • Orquestrações XLANG/s

      Se SQL Server for local, adicione também os seguintes objetos:

      • SQLServer: Bancos de dados
      • SQLServer: Estatísticas Gerais
      • SQLServer: Gerenciador de Memória
    9. Clique em OK.

    10. Altere a caixa de valor intervalo de exemplo para 5 segundos.

      Observação

      O valor intervalo de exemplo e a hora de começar a monitorar são subjetivos. Esses valores dependem de quando o vazamento de memória é reproduzido. Como o arquivo de log pode ser grande, especifique um intervalo no qual você pode obter as informações que você deve ter sem sobrecarregar o servidor.

    11. Clique em OK.

Para parar de coletar dados, clique em Parar no menu Ação .

  • Para Windows Server 2003 ou para Windows XP

    1. Expanda logs e alertas de desempenho.

    2. Clique com o botão direito do mouse em Logs de Contador e clique em Novas Configurações de Log. A caixa de diálogo Novas Configurações de Log é exibida.

    3. Na caixa Nome , digite um nome descritivo e clique em OK.

    4. Observe o local do arquivo de log. (Você também pode clicar na guia Arquivos de Log e, em seguida, clicar em Configurar para alterar o local do arquivo de log.)

    5. Clique em Adicionar Contadores.

    6. Selecione Todos os contadores e Todas as instâncias.

    7. Na lista de objetos Performance , selecione os objetos a seguir. Clique em Adicionar depois de selecionar cada objeto.

      • Exceções do .Net CLR
      • Memória CLR do .Net
      • BizTalk: Mensagens
      • BizTalk: TDDS
      • Memória
      • Processo
      • Processador
      • Orquestrações XLANG/s

      Se SQL Server for local, adicione também os seguintes objetos:

      • SQLServer: Bancos de dados
      • SQLServer: Estatísticas Gerais
      • SQLServer: Gerenciador de Memória
    8. Clique em Fechar.

    9. Altere o valor no Intervalo de Amostragem de Dados para 5 segundos.

      Observação

      O valor intervalo de amostragem de dados e a hora de começar a monitorar são subjetivos. Esses valores dependem de quando o vazamento de memória é reproduzido. Como o arquivo de log pode ser grande, especifique um intervalo no qual você pode obter as informações que você deve ter sem sobrecarregar o servidor.

    10. Clique em OK. Para parar de coletar dados, clique com o botão direito do mouse no nome do log do contador e clique em Parar.

Obter o arquivo de despejo

Para obter o arquivo de despejo, use um dos seguintes métodos:

Método 1: automático

Criar uma regra de Memória e Manipular Vazamento com DepuraçãoDiag é a abordagem recomendada para capturar um despejo de memória. A regra Memória e Manipulação de Vazamento anexa automaticamente Leaktrack.dll. Isso é usado para rastrear alocações de memória. Para criar a regra Memória e Manipular Vazamento, siga estas etapas:

  1. Iniciar a Ferramenta de Diagnóstico de Depuração 1.1.

  2. Selecione Memória e Manipular Vazamento e clique em Avançar.

  3. Selecione o processo de Btsntsvc.exe e clique em Avançar.

  4. Na página Configurar Regra de Vazamento , siga estas etapas:

    1. Clique para selecionar o rastreamento de memória Iniciar imediatamente quando a regra for ativada marcar caixa. Caso contrário, você pode especificar um tempo de aquecimento antes queLeakTrack.dll seja injetado no processo de BTSNTSvc.exe.

    2. Clique em Configurar e, em seguida, faça o seguinte:

      • Confirme se a configuração automática de uma regra de falha está selecionada. Ao selecionar essa opção, um despejo de memória será criado automaticamente se o processo BTSNTSvc.exe for interrompido.

      • Clique para selecionar a caixa Gerar um usuário quando os bytes virtuais atingirem marcar caixa e manter o valor padrão de 1024.

      • Clique para selecionar a caixa e cada marcar adicional e mantenha o padrão de 200. Ao selecionar a opção de alcance de bytes virtuais, um despejo de memória será criado automaticamente quando os bytes virtuais usarem 1024 MB. Se os bytes virtuais aumentarem em 200 MB, outro despejo de memória será criado automaticamente.

    3. Clique em Salvar & Fechar.

    4. Clique em Próximo.

    5. Na página Selecionar Local de Despejo e Nome da Regra , clique em Avançar.

      Observação

      Você também pode alterar o caminho do arquivo de despejo na caixa Localização do Usuário nesta página.

    6. Clique em Concluir para tornar a regra ativa agora.

      Observação

      A regra status agora é Acompanhamento. Sempre que um despejo de memória for criado, o valor aumentará na coluna Contagem de Usuários na guia Regras . O local de despejo de memória padrão é C:\Program Files\DebugDiag\Logs.

Método 2: Manual

Você também pode anexar manualmente Leaktrack.dll e obter manualmente o arquivo de despejo de memória. Isso permite controlar quando o despejo de memória é criado. Para fazer isso, siga estas etapas:

  1. Iniciar a Ferramenta de Diagnóstico de Depuração 1.1.
  2. Clique na guia Processos .
  3. Clique com o botão direito do mouse no processo Btsntsvc.exe e clique em Monitorar para Vazamentos.
  4. Na caixa de diálogo Ferramenta de Diagnóstico de Depuração , clique em Sim e clique em OK.

Create uma regra de falha para monitorar o mesmo processo de Btsntsvc.exe caso o processo pare antes que você possa criar o despejo de memória:

  1. Iniciar a Ferramenta de Diagnóstico de Depuração 1.1.
  2. Selecione Falha e clique em Avançar.
  3. Selecione um processo específico e clique em Avançar.
  4. Selecione o mesmo processo de Btsntsvc.exe e clique em Avançar.
  5. Na página Configuração Avançada (Opcional), clique em Avançar.
  6. Na caixa de diálogo Selecionar Local de Despejo e Nome da Regra (Opcional), clique em Avançar.
  7. Selecione Ativar a regra agora e clique em Concluir.

Quando o processo atingir de 60% a 80% da RAM, clique com o botão direito do mouse no processo de Btsntsvc.exe e clique em Create Usuário Completo. Se o processo BizTalk for interrompido antes que você possa criar o despejo de usuário, a regra Crash deverá entrar em vigor e criar o despejo de memória.

Parar o registro em log Monitor de Desempenho

Se você estiver capturando um despejo de memória e Monitor de Desempenho dados, pare Monitor de Desempenho registro em log cerca de dois minutos após a criação do despejo de memória.

Analisar o arquivo de despejo

Para ajudar a determinar a causa de um vazamento de memória, você pode usar a ferramenta Diagnóstico de Depuração para analisar o arquivo de despejo. Para fazer isso, siga estas etapas:

  1. Clique na guia Análise Avançada .
  2. Clique em Adicionar Arquivos de Dados e localize o arquivo .dmp.
  3. Selecione o script Análise de Pressão de Memória e clique em Iniciar Análise.

Por padrão, um arquivo de relatório de análise (o arquivo .mht) será criado na C:\Program Files\DebugDiag\Reports pasta quando a análise for concluída. O arquivo de relatório também será exibido em seu navegador. O arquivo de relatório contém os resultados da análise. Além disso, o arquivo de relatório pode conter recomendações de como resolve o vazamento de memória.

Se você usar DLLs personalizadas, poderá adicionar o caminho do símbolo dos arquivos .pdb personalizados para análise. Para fazer isso, siga estas etapas:

  1. Abra a ferramenta Depurar Diagnóstico.
  2. No menu Ferramentas , clique em Opções e Configurações.
  3. Na caixa Caminho do símbolo Pesquisa para depuração, digite o caminho do símbolo.

Se você quiser ajuda para analisar o arquivo de despejo, entre em contato com os Serviços de Suporte ao Cliente da Microsoft. Para obter uma lista completa de números de telefone dos Serviços de Suporte ao Cliente e informações sobre os custos de suporte, visite o Suporte de Contato.

Antes de entrar em contato com os Serviços de Suporte ao Cliente, compacte o arquivo de despejo, o log Monitor de Desempenho, o arquivo de relatório de análise e os logs de eventos atualizados (arquivos.evt). Talvez você precise enviar esses arquivos para um engenheiro de suporte BizTalk Server.