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!