2010-11-17 17 views
3

J'ai une grande application .NET qui atteint actuellement une taille de jeu de travail privé de 865 Mo. J'ai donc couru VMMap et j'ai vu que le tas fait environ 587 Mo et que le tas géré est seulement de 255 Mo (aussi jeu de travail privé).Heap vs Managed Heap

Est-il normal que tout ce code non géré utilise autant de mémoire (que je suppose être utilisé par le .net runtime)?

Remarque: J'ai utilisé WinDbg avec l'extension SOS. Le problème n'est pas la consommation de mémoire dans le tas géré, mais le tas "non géré".

Capture d'écran de VMMap: http://img687.imageshack.us/img687/1529/vmmap.png

Plus d'info: Taille totale: 1487MB Commited: 1359MB Privé: 931MB total WS: 967MB WS Privé: 865MB Gratuit (Taille): 609MB

Merci d'avance.

Répondre

0

oui! Les objets non gérés, s'ils ne sont pas libérés correctement, peuvent même entraîner une fuite de mémoire. Une fois, j'ai trouvé obcconnection objet en train de manger des concerts de RAM (il essayait d'ouvrir/fermer les connexions dans une boucle). tellement que l'application serait finalement sortir de la mémoire et s'écraser.

quels objets non gérés avez-vous avec?

0

Utilisez CLRProfiler (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a362781c-3870-43be-8926-862b40aa0cd0&DisplayLang=en) pour voir quels objets sont sur le tas.

Remarque: La version .NET 2.0 fonctionne également avec .NET 4.0.

+1

FYI, .NET 3.5 utilise CLR 2.0 - c'était 4.0 qui l'a mis à jour –

+0

peut-être plus léger et rapide pour démarrer est SOS http://msdn.microsoft.com/en-us/library/bb190764.aspx – user44298

+0

@Richard merci, édité. – Nick