ID do artigo: 918643 - Última revisão: segunda-feira, 28 de fevereiro de 2011 - Revisão: 1.0 Como solucionar problemas de vazamento de memória ou uma exceção de falta de memória no processo do BizTalk Server
Nesta páginaSumárioVazamentos de memória são um problema comum. Talvez você precise tente
várias etapas para encontrar a causa específica de um vazamento de memória ou uma exceção de falta de memória (OOM) no Microsoft BizTalk Server. Este artigo discute as considerações importantes ao avaliar o uso de memória e possíveis problemas relacionados à memória. Essas considerações incluem o seguinte:
INTRODUÇÃOEste artigo descreve como solucionar problemas de vazamento de memória ou
uma exceção de falta de memória no processo do BizTalk Server do Microsoft BizTalk
Servidor. Mais InformaçõesO processo do 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
Porcentagem de RAM física. Um vazamento de memória pode causar uma exceção de falta de memória
Quando o uso da memória aumenta até que o processo é executado fora da memória do sistema ou
até que o processo pára de funcionar. Quando esse problema ocorre, uma mensagem de aviso semelhante a seguinte mensagem é registrada no log de eventos: Evento
Tipo: aviso Tipo de evento: aviso Considerações importantesUso da memória RAM e memória físicaPorque ele pode ter um comportamento esperado para um processo de cerca de metade a RAM física, use o uso da memória como uma diretriz. Por exemplo, se o BizTalk Server possui 4 gigabytes (GB) de RAM e o processo do BizTalk Server usa cerca de 500 megabytes (MB) de RAM, pode não haver vazamento. Se o processo do BizTalk Server usa cerca de 1 GB de RAM, pode 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 longa ou uma orquestração. Certifique-se de que você sabe quanta memória o host do BizTalk normalmente usa para determinar se um vazamento de memória ou a condição de memória alta está ocorrendo.Mensagens grandesQuando o 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. Para obter mais informações sobre as mensagens grandes, visite os seguintes sites da Microsoft Developer Network (MSDN):http://blogs.msdn.com/biztalk_core_engine/archive/2005/02/28/381700.aspx
(http://blogs.msdn.com/biztalk_core_engine/archive/2005/02/28/381700.aspx)
. aspx (BTS.10) http://msdn.microsoft.com/en-us/library/aa560481
(http://msdn.microsoft.com/en-us/library/aa560481(BTS.10).aspx)
Além disso, considere o uso de memória alta pode ser esperado se BizTalk
O servidor está processando mensagens grandes. Talvez você queira atualizar o hardware para
atende os requisitos de desempenho do BizTalk Server em seu ambiente.Quanto tempo demora para reproduzir o vazamento de memóriaVazamentos de memória podem ocorrer imediatamente ou eles podem se acumular em tempo. Ambos os cenários são comuns.Uso da opção /3GB em computadores de 32 bitsNormalmente, um processo pode acessar 2 GB de espaço de endereço virtual. O/3GBswitch é uma opção para sistemas que requerem mais memória endereçável. Esta opção pode aumentar o uso da memória para o processamento de mensagens. No entanto, o/3GBswitch permite que apenas 1 GB de memória endereçável para operações no modo kernel. Além disso, essa opção pode aumentar o risco de ficar sem memória de pool.Para obter mais informações sobre o/3GBAlternar, visite o seguinte site da Microsoft Developer Network (MSDN): http://msdn.microsoft.com/en-us/library/ms791558.aspx
(http://msdn.microsoft.com/en-us/library/ms791558.aspx)
Quando o/3GBswitch é habilitada em uma versão de 32 bits do Windows, o processo poderá acessar 3 GB de endereço virtual
Se o processo for grande-endereço de espaço ciente. Um processo é o endereço grande reconhecimento quando o executável tem o sinalizador IMAGE_FILE_LARGE_ADDRESS_AWARE definido no cabeçalho da imagem. Como o processo do BizTalk é endereço grande ciente, BizTalk será beneficiada com a opção /3GB.Se estiver executando uma instância de host do BizTalk de 32 bits em uma versão de 64 bits do Windows (AMD64), os benefícios do processo de BizTalk da memória de 4 GB de espaço de endereço como o BizTalk é endereço grande ciente. Portanto, mover os aplicativos de memória alta para um servidor de 64 bits pode ser a melhor solução. Um processo do 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 particulares usados pelo processo. Uma instância de host do BizTalk (que é um.NET Framework aplicativo) pode receber um erro de falta de memória antes do valor de Bytes virtuais atinge 2 GB. Isso 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/3GBswitch) é de 2 GB. Para obter uma explicação de por que isso pode ocorrer, visite os seguintes sites da Microsoft Developer Network (MSDN): http://msdn.microsoft.com/en-us/library/ms972959.aspx
(http://msdn.microsoft.com/en-us/library/ms972959.aspx)
http://blogs.msdn.com/TESS/archive/2005/11/25/496898.aspx
(http://blogs.msdn.com/tess/archive/2005/11/25/496898.aspx)
O/3GBswitch também aumenta o máximo de bytes particular do processo de 800 MB BizTalk 1800 MB. Para obter mais informações sobre.NET Framework o desempenho de aplicativos com o/3GBopção ativada, visite o seguinte site da Microsoft Developer Network (MSDN):http://msdn2.microsoft.com/en-us/library/ms998583.aspx
(http://msdn2.microsoft.com/en-us/library/ms998583.aspx)
A tabela a seguir resume essas informações e inclui os limites práticos para bytes virtuais e particular.Recolher esta tabela
http://msdn.microsoft.com/en-us/library/aa366778.aspx
(http://msdn.microsoft.com/en-us/library/aa366778.aspx)
A tabela a seguir lista PAE e 3 GB de capacidade para versões diferentes do BizTalk Server.Recolher esta tabela
Componentes do BizTalk que são executados dentro de um processo do Internet Information Services (IIS) pode também se beneficiam quando o/3GBswitch está ativado. O/3GBswitch não é suportado em computadores que estejam executando o Windows SharePoint Services 2. 0 ou posterior ou o SharePoint Portal Server 2003 SP2 ou versões posteriores.Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: 933560
(http://support.microsoft.com/kb/933560/
)
A opção /3GB do Windows Server 2003 não é suportada no Windows SharePoint Services 2. 0 ou nas versões mais recentes ou no SharePoint Portal Server 2003 Service Pack 2 ou em versões posteriores Uso de componentes personalizadosSe você usar componentes personalizados, como componentes de serviço, ou de tubulações Você deve saber o que fazem esses componentes. Você também deve saber o possível efeito desses componentes em uso de memória. A problema de memória comum ocorre quando um componente está transformando um documento. O operação de transformação é uma operação de usar muita memória. Quando um documento é o BizTalk Server transformados, passa o fluxo de mensagens para o Microsoft.NET FrameworkXslTransformclasse dentro do processo do BizTalk.Outro problema comum ocorre quando há manipulação intensiva de seqüência de caracteres. Seqüência de caracteres intensivo manipulação pode consumir muita memória. Para obter mais informações sobre as maneiras melhorar o desempenho, visite o seguinte site da Microsoft Developer Network (MSDN): http://msdn2.microsoft.com/en-us/library/ms998547
(http://msdn2.microsoft.com/en-us/library/ms998547)
Versão do.NET FrameworkA Microsoft.NET Framework 2. 0 e o.NET Framework 1. 1 tem um comportamento diferente de memória. Portanto, você poderá ver resultados variados entre eles. Se você estiver usando o.NET Framework, confirme que a última.NET Framework Service Pack 1 está instalado. Esses service packs corrigem diversos problemas de memória conhecidos. Para obter mais informações, clique nos números abaixo:945757 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;945757) Problemas corrigidos na.NET Framework 2. 0 Service Pack 1 867460 (http://support.microsoft.com/kb/867460/ ) Lista de bugs corrigidos na.NET Framework 1. 1 Service Pack 1 Número de processadoresO common language runtime (CLR) tem o seguinte lixo Coletores (GCs):
Se o computador. Isto é com o BizTalk Server é um sistema de processador único, o.NET Framework usa a versão de estação de trabalho do mecanismo de execução. Este é o padrão. comportamento. O algoritmo de alocação de coletor de lixo da estação de trabalho não for projetado para escalar ou para throughput máximo. Usa este coletor de lixo métodos de coletor de lixo simultâneas. Esses métodos são projetados para aplicativos que têm interfaces de usuário complexa. Tais aplicativos podem exigir. coleta de lixo mais agressiva. ImportanteNesta seção, método ou tarefa contém etapas que informam sobre como modificar o registro. No entanto, sérios problemas poderão ocorrer se você modificar o registro incorretamente. Portanto, certifique-se de que você siga estas etapas cuidadosamente. Para maior proteção, faça backup do registro antes de modificá-lo. Em seguida, você poderá restaurar o registro se ocorrer um problema. Para obter mais informações sobre como fazer backup e restaurar o registro, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: 322756
(http://support.microsoft.com/kb/322756/
)
Como fazer backup e restaurar o registro no Windows Às vezes, pode ser apropriado executar a versão de estação de trabalho do mecanismo de execução em um sistema com vários processadores. Você pode usar a seguinte chave do registro para alternar para a versão de estação de trabalho do mecanismo de execução.O BizTalk 2006 e versões posterioresCrie a seguinte chave do registro de seqüência de caracteres de hospedagem do CRL com os valores correspondentes:$ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvcBizTalkHostNameHospedagem de \CLR Nome: Flavor Dados: wks O BizTalk 2004Crie a seguinte chave do registro de seqüência de caracteres de hospedagem do CRL com os valores correspondentes:{HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvcGUID} Host \CLR Nome: Flavor Dados: wks Para obter mais informações, visite os seguintes sites da Microsoft Developer Network (MSDN): http://msdn2.microsoft.com/en-us/library/ms973838
(http://msdn2.microsoft.com/en-us/library/ms973838)
http://blogs.msdn.com/TESS/archive/2008/04/17/How-does-the-GC-Work-and-What-are-the-sizes-of-the-different-generations.aspx (http://blogs.msdn.com/tess/archive/2008/04/17/how-does-the-gc-work-and-what-are-the-sizes-of-the-different-generations.aspx) Causas comuns e resoluçõesUso de memória de processo e limites de otimização do uso de memória físicaOUso de memória de processoeUso de memória físicalimites de otimização pode ser alterada no BizTalk Server 2006 e em versões posteriores.
http://msdn.microsoft.com/en-us/library/aa559628.aspx
(http://msdn.microsoft.com/en-us/library/aa559628.aspx)
Dehydration otimização limitesOs limites de dehydration de memória padrão podem causar muito dehydration quando orquestrações são executadas em um host de 64 bits. Para obter mais informações sobre esse problema, consulte oPropriedades padrão de dehydrationtópico no seguinte site da Microsoft Developer Network (MSDN):http://msdn.microsoft.com/en-us/library/aa560586.aspx
(http://msdn.microsoft.com/en-us/library/aa560586.aspx)
Observaçãohosts de 64 bits são suportados no BizTalk Server 2006 e versões posteriores.Em um hardware equivalente em uma instância de host de 32 bits, dehydration observado é nominal quando as mesmas orquestrações são executadas usando o dehydration de memória padrão limites de otimização. Como a arquitetura de 64 bits fornece espaço de endereço de memória expandida (16 TB em vez de 4 GB), instâncias de host de 64 bits são alocadas significativamente mais memória do que instâncias host de 32 bits. Isso pode causar os limites de otimização de memória padrão seja excedido. Para contornar esse comportamento, altere os valores de VirtualMemoryThrottlingCriteria e PrivateMemoryThrottlingCriteria no arquivo BTSNTSvc64.exe.config. Use os Bytes de Process\Virtual e os contadores do Monitor de desempenho de Bytes de Process\Private para determinar a maior quantidade de memória alocada por uma instância de orquestração.
Se o valor do contador de desempenho do sistema Bytes de \Process\Private 435689400 bytes (415 MB), defina o valor de OptimalUsage para PrivateMemoryThrottlingCriteria para 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 seriam especificados no arquivo BTSNTSvc64.exe.config para reduzir a aceleração. Recolher esta tabela
<xlangs>
<Configuration>
<Dehydration>
<VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
<PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
</Dehydration>
</Configuration>
</xlangs>ObservaçãoA alta dehydration pode causar uma redução significativa no desempenho quando o banco de dados do BizTalkMsgBoxDb está em execução no SQL Server 2008. O BizTalk Server Service Packs e atualizações cumulativasO BizTalk Server service packs e atualizações cumulativas incluem as correções mais recentes. Eles incluem aqueles que afetam os problemas conhecidos de System. OutOfMemoryException.2281783 (http://support.microsoft.com/default.aspx?scid=kb;en-US;2281783) Lista de Service Pack e a atualização cumulativa para o BizTalk Server 2006 R2 Microsoft BizTalk Server 2004 Service Pack 2 (http://www.microsoft.com/downloads/en/details.aspx?FamilyId=D20B4510-E5A6-4D7B-87A1-4BD52BDD57B8&displaylang=en) HeapDeCommitFreeBlockThresholdPor padrão, o valor da chave do registro theHeapDeCommitFreeBlockThreshold é 0. Um valor 0 significa que o heap. Gerenciador de decommits cada página (KB) de 4 kilobytes que fica disponível. Liberação operações causam a fragmentação de memória virtual. O tamanho dasHeapDeCommitFreeBlockThresholdconfiguração no Gerenciador de heap dependerá do tipo de trabalho que o sistema está fazendo. Um tamanho de 0x00040000 é de partida recomendados valor.Considere as seguintes informações antes de alterar o valor. da HeapDeCommitFreeBlockThreshold Registro
chave:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Gerenciador Nome do valor: HeapDeCommitFreeBlockThreshold Tipo de valor: REG_DWORD Dados do valor: 0x00040000 (Este é o valor de partida recomendado). Valor padrão: ausente 315407
(http://support.microsoft.com/kb/315407/
)
A chave de registro "heapdecommitfreeblockthreshold" Transformar as operaçõesQuando o BizTalk Server executa operações de transformação XML em relativamente grande de mensagens em uma porta de recepção, em uma porta de envio, ou em XLANG, transformações XSL carregar toda a mensagem na memória..Para resolver esse problema, use um dos seguintes métodos:
A maioria dos functoids do BizTalk padrão é implementada como script embutido. Esses itens podem causar System. Byte [] objetos coletar na memória. Para minimizar o consumo de memória, é recomendável que você coloque qualquer mapa que usa esses functoids em um assembly pequeno. Em seguida, fazer referência a esse assembly. Use o gráfico a seguir para determinar quais functoids usar script embutido e quais functoids não use script embutido. Na segunda coluna, "Sim" significa que este functoid é implementada como um script embutido e que ele fará com que o System. Byte [] objetos coletar na memória. "Não" significa que este functoid não é implementada como script embutido, e que ele fará com que objetos do System. Byte [] coletar na memória. Recolher esta tabela
http://msdn2.microsoft.com/en-us/library/aa560481.aspx
(http://msdn2.microsoft.com/en-us/library/aa560481.aspx)
Valores de atributo grandes e elemento grandeQuando o BizTalk Server executa um recebimento pipeline ou um pipeline de envio em um documento XML, a carga é processada no Se o documento contém um ou mais dos seguintes entidades de memória:
Componentes de pipeline personalizadosVocê está usando um componente de pipeline personalizado que carrega o todo fluxo na memória. Todos os componentes que estão incluídos com o BizTalk Server com exceção de transformações, suporte a streaming. Esses componentes não usam o máximo memória durante o fluxo contínuo. No entanto, os componentes de pipeline personalizados podem não suportar fluxo contínuo.Fluxo sob carga excessivaEnvie hosts fiquem sem memória quando eles operam sob carga excessiva. BizTalk Server envie pipelines e enviar o streaming de suporte de adaptadores. Em cada componente de fluxo contínuo, carrega um pequeno fragmento do fluxo na memória. Porque cada mensagem inclui outras estruturas de dados, com uma mensagem o contexto que pode ser grandes ou pequenos, esse comportamento afeta o comportamento do BizTalk Servidor sob carga excessiva.O comportamento do BizTalk Server é afetado. porque o mecanismo carrega um número pré-configurado de mensagens. O número de mensagens que carrega o mecanismo é baseada nos valores que aparecem na Campos LowWaterMark e HighWaterMark da tabela Adm_serviceClass. A tabela Adm_serviceClass está no banco de dados de gerenciamento do BizTalk. Esses valores. controlar o número de mensagens do BizTalk Server processa ou envia à mesmo tempo. OHighWaterMarko valor é 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 com oito processadores, o host de envio tentará processar mensagens de 1600 (200 * 8) em o mesmo tempo. Se você assumir que cada mensagem é de 50 KB, as mensagens igual a 80 MB (1, 50 * 600 = 80, 000 KB). Para resolver esse problema, você pode alterar oHighWaterMarkvalor e oLowWaterMarkvalor no banco de dados. Os valores que você usa dependem do tamanho as mensagens. Para obter mais informações sobre causas comuns de um falta de memória da condição, consulte a seção "Memória crescimento no BizTalk Messaging" no seguinte site da Microsoft: http://blogs.msdn.com/biztalkperformance
(http://blogs.msdn.com/biztalkperformance)
O BizTalk Server 2006 e versões posteriores, você pode alterar o host padrão
configurações de otimização. Para obter mais informações sobre como alterar o host padrão
configurações de otimização, visite o seguinte site da Microsoft Developer Network (MSDN):http://msdn2.microsoft.com/en-us/library/aa559628.aspx
(http://msdn2.microsoft.com/en-us/library/aa559628.aspx)
Simplificar o problema.Se você identificar um vazamento de memória, tente determinar a causa removendo componentes personalizados ou simplificando um mapa. Além disso, tente reproduzir o problema por meio de uma orquestração simple ou uma solução simples. Normalmente, você deve criar separado receber hosts para receberem os adaptadores. Você deve também Crie hosts de envio separado para adaptadores de envio. Quando você usa esse método, cada adaptador pode executar em um processo separado. Portanto, se o processo do BizTalk Server passa por uma condição de falta de memória, você irá sabe quais componentes estão envolvidos.As etapas de solução de problemasPara solucionar uma condição de falta de memória, use a depuração Ferramenta de diagnóstico para monitorar as alocações de memória ao longo do tempo. O diagnóstico de depuração ferramenta pode criar e analisar um arquivo de despejo de vazamento de memória (. dmp). Quando você solucionar problemas de vazamento de memória, o objetivo é anexar Leaktrack.dll antes do alto Reproduz a condição de memória para capturar o aumento da memória ao longo do tempo. LeakTrack.dll é fornecido com a ferramenta Debug Diagnostic.
Como usar o registo do Monitor de desempenhoSelecione os dados para fazer logonPara selecionar os dados para fazer logon, use o método apropriado para seu sistema operacional:
Obtenha o arquivo de despejoPara obter o arquivo de despejo, use um dos seguintes métodos:
Parar o log do Monitor de desempenhoSe você estiver capturando um despejo de memória e dados de desempenho do sistema, pare o Monitor de desempenho log cerca de dois minutos após o despejo de memória é criado.Analisar o arquivo de despejoPara ajudar a determinar a causa de um vazamento de memória, você pode usar a depuração Ferramenta de diagnóstico para analisar o arquivo de despejo. Para fazer isso, execute estas etapas:
Se você usar o custom DLLs, você pode adicionar o caminho de símbolo dos arquivos. pdb personalizados para análise. Para fazer Isso, execute estas etapas:
http://support.microsoft.com/contactus/?ws=support
(http://support.microsoft.com/contactus/?ws=support)
Antes de entrar em contato com o atendimento ao cliente, compacte o arquivo de despejo, o log de desempenho do sistema, o arquivo de relatório de análise e os logs de eventos de atualizada (arquivos. evt). Talvez você precise enviar que esses arquivos para um servidor BizTalk engenheiro de suporte.A informação contida neste artigo aplica-se a:
Tradução automáticaIMPORTANTE: 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 traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado. Clique aqui para ver a versão em Inglês deste artigo: 918643
(http://support.microsoft.com/kb/918643/en-us/
)
| Outros Recursos Outros Sites de Suporte
ComunidadesObtenha Ajuda AgoraTraduções deste artigo |






Windows Live
Facebook
Twitter
Linkedin
Digg it
Yahoo
Delicious
StumbleUpon
Yammer
Reddit
Technorati
FriendFeed
Email


Voltar para o início
