DA0018: Aplicativo de 32 bits em execução no processo gerenciado limites de memória

Identificação da regra

DA0018

<strong>Categoria</strong>

O uso de ferramentas de criação de perfil

Método de criação de perfil

Amostragem

Message (Mensagem)

Gerenciado de alocações de memória se aproximando do limite padrão para um processo de 32 bits. Seu aplicativo pode ser vinculado a memória.

Tipo de regra

Aviso

Quando você cria o perfil usando a amostragem.NET métodos de contenção de memória ou recursos, você deve coletar amostras de pelo menos 10 para disparar esta regra.

Causa

Os dados de sistema coletados durante a criação de perfil executar indicam o.Memória do NET Framework heaps aproximou o tamanho máximo que o gerenciado pilhas pode chegar em um processo de 32 bits. Esse tamanho máximo é um valor padrão. Baseia-se a quantidade total do espaço de endereço do processo que pode ser alocado para bytes particulares. O valor indicado é o máximo observado o valor de pilhas enquanto o processo perfilado estava ativo. Considere a criação de perfil novamente usando o.NET memória definindo o perfil de método e otimizando o uso de recursos gerenciados pelo aplicativo.

Quando o tamanho do gerenciados Heaps abordar o limite padrão, o processo de coleta de lixo automática talvez precise ser invocado com mais freqüência. Isso aumenta a sobrecarga de gerenciamento de memória.

A regra é acionado apenas para os aplicativos de 32 bits executados em máquinas de 32 bits.

Descrição da regra

A Microsoft.NET common language runtime (CLR) fornece um mecanismo de gerenciamento automático de memória que usa um coletor de lixo para recuperar memória de objetos que o aplicativo não usa mais. O coletor de lixo é orientado a geração, com base na suposição de que muitas alocações são de curta duração. Variáveis locais, por exemplo, devem ser curta duração. Objetos recém-criados inicie na geração 0 (Ger 0) e, em seguida, de andamento para a geração 1 quando eles sobrevivem a coleta de lixo executar e finalmente a transição para a geração 2 se o aplicativo ainda usa-los.

Objetos gerenciados que são mais de 85 KB são alocados na pilha de objetos grandes, onde eles estão sujeitos a coleta de lixo e a compactação de objetos menores menos freqüente. objetos grandes são gerenciados separadamente porque supõe que eles são mais persistentes e porque a mistura persistente e grandes objetos com objetos de menores freqüentemente alocados podem produzir cast pior a fragmentação da heap.

O tamanho total de gerenciados heaps abordar o limite padrão, a sobrecarga de gerenciamento de memória geralmente aumenta até o ponto onde ela pode começar a afetar a capacidade de resposta e a escalabilidade do aplicativo.

Como investigar um aviso.

Clique duas vezes a mensagem na janela Error List para navegar até o marcas modo de exibição. Encontrar o .NET CLR Memory\ # Bytes in all Heaps e # total committed bytes colunas. Determine se existem fases específicas da execução do programa onde a alocação de memória gerenciada é maior do que outras fases. Comparar os valores da # bytes in all Heaps coluna para a taxa de coleta de lixo é relatado na .NET CLR Memory\ # de coletas de Gen 0, .NET CLR Memory\ # de coletas de Gen 1, e .NET Memory\ # de Gen 2 coleções do CLR colunas para determinar se o padrão de alocações de memória gerenciada está afetando a taxa de coleta de lixo.

Em um.Aplicativo do NET Framework, o common language runtime limita o tamanho total do gerenciado pilhas para ligeiramente menor que metade do tamanho máximo da parte área particular de um espaço de endereço do processo. Para processos de 32 bits executados em uma máquina de 32 bits, 2 GB representa o limite superior da parte privada de espaço de endereço do processo. Como o tamanho total de pilhas gerenciadas começa a abordar seu limite padrão, a sobrecarga de gerenciamento de memória pode aumentar e diminuir o desempenho do aplicativo.

Se a sobrecarga de memória gerenciada excessiva é um problema, considere uma dessas opções:

  • Otimizando o uso do aplicativo de recursos de memória gerenciada

    - ou -

  • tomando medidas para aliviar as restrições de arquiteturais no tamanho máximo de memória virtual para um processo de 32 bits

Para otimizar o uso do aplicativo de recursos de memória gerenciada, coletar dados de alocação de memória gerenciada um.Execução de profiling de alocação de memória de NET. Revisão do Ferramentas de criação de perfil.Exibições de dados de memória de NET relatórios para compreender o padrão do aplicativo de alocação de memória.

Use o Exibição de tempo de vida do objeto para determinar qual dos dados do programa os objetos são sobreviventes em geração e sendo recuperada de lá.

Use o .Exibição de alocações de memória de NET para determinar o caminho de execução que resultou nessas alocações.

Para obter mais informações sobre como melhorar o desempenho de coleta de lixo, consulte.Artigo técnico do NET Framework, Noções básicas do coletor de lixo e dicas de desempenho no site do MSDN.

Para obter o alívio de arquitetura de restrições de memória virtual no tamanho da parte privada de um espaço de endereço do processo, tente executar esse processo de 32 bits em uma máquina de 64 bits. Um processo de 32 bits em uma máquina de 64 bits pode adquirir até 4 GB de memória de virtual private.

Um processo de 64 bits executados em uma máquina de 64 bits pode adquirir até 8 TB de memória virtual. Considere a possibilidade de re-compiling o aplicativo seja executado como um aplicativo nativo de 64 bits. Esta regra é somente informativa e pode não exigir ação corretiva.