Excepção de memória esgotada numa aplicação gerida que está a ser executado no 64-bit .NET Framework

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: 3152158
Sintomas
Tem uma aplicação gerida direccionada a 64-bit Microsoft .NET Framework 4.6.1. Esta aplicação inicia uma excepção de memória esgotada de CLR com a seguinte mensagem específica:

OutOfMemoryException: "memória insuficiente dentro do intervalo de espaço de endereços especificado para continuar a execução do programa."
Causa
Esta excepção de memória esgotada é propagada por CLR quando o subsistema do Gestor de código não é possível atribuir memória dentro de um intervalo de espaço de endereço específico para saltar stubs. (Estes atalhos stubs correspondem ao método que chama entre DLLs que se encontram 2 GB ou mais entre si no espaço de endereço.) Deve existir espaço num raio de 2 GB, o método de chamada para armazenar o stub de salto para uma chamada de método de 64 bits. Não existe nenhuma forma de segurança de uma aplicação para recuperar deste erro específico. Por conseguinte, o estado da aplicação depois de encontrar este erro é desconhecido e deve ser considerada danificado. É a única forma de recuperar reiniciar a aplicação.
Como contornar
Para contornar este problema, utilize um dos seguintes métodos de definição:
  • Implementa uma definição global, adicionando a seguinte chave de registo e o valor:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework

    NGenReserveForjumpStubs= dword:00000005

  • Implementar uma definição de nível da aplicação adicionando (ou intercalar) a seguinte secção ao ficheiro de configuração de aplicação:
    <configuration>    <runtime> <NGenReserveForJumpStubs value="5" />    </runtime></configuration>
Explicação: NGenReserveForJumpStubs faz com que o CLR reservar uma percentagem do espaço do endereço de salto stubs perto de cada imagem NGen carregada. Recomendamos que utilize um valor igual ou superior a 5, se tiver esta excepção de OutOfMemory.
Mais Informação

Para programadores

  • O .NET Framework codifica método chamadas como relativos saltos de 32 bits por motivos de desempenho. Num sistema de 64 bits, autor da chamada e o destinatário da chamada podem ser ainda mais uma distância de 2 GB (no espaço de endereço). Porque este excede o intervalo de endereços de um desvio de 32 bits assinado, o .NET criará um stub de salto no prazo de 2 GB do chamador. Este salto stub pode, em seguida, criar "completo" vai para qualquer ponto no espaço de endereço de 64 bits.
  • Os JIT e NGen atenuações funcionam de modo ligeiramente diferente. As duas das quais reservam o espaço de endereços adicionais até à frente, mas o ponto em que esta reserva é feita difere entre os dois.
  • NGenReserveForJumpStubs é uma percentagem de (de tamanho de imagem NGen virtualpercentReserveForJumpStubs).
  • Um stub salto típica é de 12 bytes. Para mais informações, consulte JUMP_ALLOCATE_SIZE.
  • A memória está atribuída e reservada junto do endereço onde a imagem de NGen foi carregada (o algoritmo exacto é EEJitManager::EnsureJumpStubReserve). A memória é consolidada quando é necessário atribuir um stub salto e quando não está disponível nenhum outro espaço de endereço adequados.
  • Medidas de atenuação anteriormente mencionadas não modifica o conteúdo de imagens de NGen. As imagens NGen tem o mesmo disco requisitos de espaço com e sem atenuação.
  • Não existe actualmente nenhuma boa forma de detectar quando a aplicação está a ficar perto do limite. Tem de monitorizar para OutOfMemoryException determinar se o espaço reservado é suficiente.
  • Poderá receber a OutOfMemoryException, mesmo se existir uma grande quantidade de memória não utilizada uma vez que este erro específico está relacionado com a disponibilidade de memória num raio de intervalo de endereços de 2 GB do chamador.
  • Não deve alterar o valor predefinido de CodeHeapReserveForJumpStubs, porque este poderá não estar relacionado com o problema acima descrito. Não observámos caso em que a aplicação efectiva teria ajustar esta definição como uma solução.
  • Definir NGenReserveForJumpStubs para um valor significativamente mais elevado pode conduzir a desempenho reduzido e o risco de expor a outros problemas subtis.

Para utilizadores informáticos

  • Este problema também poderá ocorrer noutras versões do .NET Framework. No entanto, a solução é actualmente aplicável apenas ao enquadramento .NET 4.6.1.
  • Este é um problema muito raro que afecta apenas as cargas de trabalho muito grandes, com um padrão de execução muito específicos. Mais de 99 por cento de todas as cargas de trabalho nunca irá detectar este problema.
  • Depois da aplicação lança uma excepção de OutOfMemory, é a única forma recomendada para recuperar reiniciar a aplicação.

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 3152158 - Última Revisão: 05/10/2016 16:53:00 - Revisão: 2.0

Microsoft .NET Framework 4.6.1

  • kbsurveynew kbtshoot kbexpertiseinter kbmt KB3152158 KbMtpt
Comentários