3

I have a big .NET application that is currently hitting a private working set size of 865MB.

So I ran VMMap and saw that the Heap is about 587MB and Managed Heap is only 255MB (also private working set).

Is it normal to have all this unmanaged code using so much memory (that I suppose is being used by the .net runtime)?

Note: I've used WinDbg with SOS extension. The problem is not the memory consumption in the managed heap but the "unmanaged" heap.

Screenshot of VMMap: http://img687.imageshack.us/img687/1529/vmmap.png

More info: Total size: 1487MB Commited: 1359MB Private: 931MB Total WS: 967MB Private WS: 865MB Free (Size): 609MB

Thanks in advance.

trincot
  • 317,000
  • 35
  • 244
  • 286
Tiago
  • 737
  • 5
  • 20

2 Answers2

0

yes! unmanaged objects if not freed up properly can even cause more memory to leak. I once found obcconnection object eating up gigs of RAM (it was trying to open/close connections in a loop). so much so that the app would eventually go out of memory and crash.

what unmanaged objects are you dealing with?

Mrchief
  • 75,126
  • 20
  • 142
  • 189
0

Use CLRProfiler (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a362781c-3870-43be-8926-862b40aa0cd0&DisplayLang=en) to see what objects are on the heap.

Note: The .NET 2.0 version also works with .NET 4.0.

Nick
  • 13,238
  • 17
  • 64
  • 100
  • maybe more lightweight & quick to start is SOS http://msdn.microsoft.com/en-us/library/bb190764.aspx – user44298 Nov 17 '10 at 22:37
  • Actually I think that wont be much help since I've already analyzed the CLR objects in the managed heap in WinDbg and everything seemed fine. – Tiago Nov 17 '10 at 22:42