Compreendendo os contadores de desempenho da memória

[Atualização - 30/09/2010]

Desde que estudei muito sobre esses e outros tópicos relacionados, escreverei as dicas que reuni de minhas experiências e sugestões fornecidas nas respostas aqui-

1) Use o criador de perfil de memória (tente o CLR Profiler, para começar) e encontre as rotinas que consomem o máximo de mem e os ajuste, como a reutilização de grandes matrizes, e tente manter as referências aos objetos no mínimo.

2) Se possível, aloque objetos pequenos (menos de 85k para o .NET 2.0) e use conjuntos de memórias se puder evitar o alto uso da CPU pelo coletor de lixo.

3) Se você aumentar as referências a objetos, é responsável por desmarcá-las no mesmo número de vezes. Você terá tranqüilidade e o código provavelmente funcionará melhor.

4) Se nada funcionar e você ainda não tiver noção, use o método de eliminação (comentar / pular código) para descobrir o que está consumindo mais memória.

O uso de contadores de desempenho de memória em seu código também pode ajudá-lo.

Espero que estas ajudem!

[Pergunta original]

Oi!

Estou trabalhando em c # e meu problema está com exceção de memória insuficiente.

Eu li um excelente artigo sobre LOH aqui ->http://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/

Awesome read!

E,http://dotnetdebug.net/2005/06/30/perfmon-your-debugging-buddy/

Meu problema:

Estou enfrentando um problema de falta de memória em um aplicativo de desktop de nível corporativo. Tentei ler e entender coisas sobre perfil de memória e contador de desempenho (tentei o WinDBG também! - um pouco), mas ainda não entendi nada sobre coisas básicas.

Eu tentei o CLR Profiler para analisar o uso de memória. Foi útil em:

Mostrando-me quem alocou grandes pedaços de memória

Que tipo de dados usou memória máxima

Mas, ambos, CLR Profiler e Performance Counters (como compartilham os mesmos dados), falharam em explicar:

Os números coletados após cada execução do aplicativo - como entender se há alguma melhoria?!?!

Como comparo os dados de desempenho após cada execução - o número menor / maior de um contador específico é bom ou ruim?

O que eu preciso:

Estou procurando as dicas sobre:

Como liberar (sim, certo)gerenciou objetos de tipo de dados (como matrizes, grandes cadeias) - mas não fazendo chamadas GC.Collect, se possível. Eu tenho que lidar com matrizes de bytes de comprimento como 500 KB (tamanho inevitável :-() de vez em quando.

Se ocorrer fragmentação, como compactar a memória - como parece que o .NET GC não esteja realmente fazendo isso e causando OOM.

Além disso, qual é exatamente o limite de 85 KB para LOH? Esse é o tamanho do objeto do tamanho geral da matriz? Isso não está muito claro para mim.

O que os contadores de memória podem dizer se as alterações de código estão realmente reduzindo as chances de OOM?

Dicas que eu já conheço

Defina objetos gerenciados como nulos - marque-os como lixo - para que o coletor de lixo possa coletá-los. Isso é estranho - depois de definir umcorda[] objeto para null, o# bytes em todos os montões disparou!

Evite criar objetos / matrizes> 85KB - isso não está sob meu controle. Portanto, pode haver muito LOH.

3)

Memory Leaks Indicators:

# bytes in all Heaps increasing
Gen 2 Heap Size increasing
# GC handles increasing
# of Pinned Objects increasing
# total committed Bytes increasing
# total reserved Bytes increasing
Large Object Heap increasing

Minha situação:

Eu tenho uma máquina de 32 GB e 4 GB com o servidor Wink 2K3 SP2.Entendo que um aplicativo possa usar <= 2 GB de RAM físicaAumentar o tamanho da memória virtual (arquivo de paginação) não tem efeito nesse cenário.

Como problema de OOM, estou focando apenas nos contadores relacionados à memória.

Conselho por favor!Eu realmente preciso de ajuda, pois estou preso por falta de boa documentação!

questionAnswers(3)

yourAnswerToTheQuestion