erramentas para analisar a pegada de memória de DLLs nativas e assemblies carregados em um process
Tenho um processo com 130 MB de memória, de acordo com o gerenciador de tarefas, com apenas 11 MB de objetos .NET ativos, de acordo com dotTrace então eu estou querendo saber o que está acontecendo com os outros 120MB
Eu precisaria de uma ferramenta para listar assemblies e DLLs nativas carregadas em um processo, obter o tamanho das imagens em processo e, para cada assembly, medir o espaço de memória dos métodos JITe
ListDlls da SysInternal faz parcialmente esse trabalho. Mas ele não mede o tamanho do código JIT e apenas fornece dados brutos. Idealmente, eu gostaria de uma interface do usuário para analisar e resumir esses dados.
Recentemente, a equipe do Visual Studio relatou ter feito essa análise com a ferramenta PerfView. Isso é afirmado na postagem do blogVisual Studio 11 Beta Performance Part # 1, seção:O Maior Consumidor de VM - DLLs. Alguém tem experiência e feedback analisando Dlls nativas e pegadas de montagens com o PerfView?
Exceto ListDlls e PerfView, você recomendaria outra ferramenta?
Está bem, VMMAP aconselhado porSimon Mourier parece ser a ferramenta mais adequada para esta tarefa. @ VMMAP mostra que a maior parte da memória do conjunto de trabalho entra na Pilha Gerenciada (113 MB em verde abaixo), portanto, o problema está mais relacionado aos objetos .NET do que à memória não gerenciada. A curva verde do dente de serra é apenas uma linha do tempo das sessões de carregamento / descarregamento. Por algumas razões, minhas primeiras medidas foram completamente erradas:
Então, meu plano é:
Identifique por que o GC aloca 113 MB de heap gerenciado para 41 MB de objetos .NET? (esses números são normais? é devido à alta fragmentação?)Trabalhe para reduzir esse conjunto de 41 .NET de objetos .NET alocado