virtual memory leak? in asp.net app - OutOfMemory exception -- dotnet clr

Mike
6/27/2007 9:44:03 AM

Hello,

I have an ASP.Net app pulling a large XML stream (50 MB) and loading into an
XmlDocument object. Doing so seems to allocate several hundred MBs of
virtual memory (Seen as "virtual bytes" in perfmon). This behavior seems to
happen in the XmlDocument.Load() method.

When the XmlDocument object goes out of scope, the application releases the
"working set" after a period of time, or immediately if I call GC.Collect(),
but the allocated "virtual bytes" remain.

Loading the same XML stream again seems to re-use the allocated virtual
memory, but loading a different XML stream allocates even more virtual
memory. Eventually the application throws an OutOfMemory exception.

Why is the app not releasing the virtual memory as it reaches is memory
limits?

How can I tell the application to release the virtual memory?

Is there something about the XmlDocument object I should know?

Any commands in WinDbg that might help me see what is in virtual memory?

Thanks,

Ben Voigt [C++ MVP]
6/27/2007 11:10:09 PM

[quoted text, click to view]

Restart the process. I don't believe the Common Language Runtime ever gives
memory back to Windows.

[quoted text, click to view]

Mike
6/29/2007 10:44:00 AM

[quoted text, click to view]

Ben, Thanks for your reply.

I'm shocked that the CLR would not release memory back to Windows. Do you
have a citation you can share that would support this? And, if this is an
intentional design, justification for it?

Willy Denoyette [MVP]
6/30/2007 12:00:00 AM

[quoted text, click to view]

The CLR returns the excess memory to the OS whenever the OS asks the process
to trim it working set. However, this is not your problem. Each process in
Windows 32 bit can consume a maximum of 2GB of virtual memory space for data
and code, whenever you exceed this amount you will get an OOM exception. The
asp.net worker process however, restricts its virtual address space to a
(configurable) value which is much lower than this 2GB. By default, only 60%
of available system memory can ever be used as VAD space for the worker
process. So, for a system with 1GB of memory, that means that only 600MB can
be used by the asp.net worker process. If you want to allocate more than
this, you will have to increase the "memoryLimit" in your system.web config
file, but *much* better is to follow Mattias suggestion and use
XmlTextReader instead of XmlDocument.

Willy.

Ben Voigt [C++ MVP]
8/2/2007 12:39:46 PM

[quoted text, click to view]

Just that very few applications do. Here is a quote from MSDN:

"The HeapCreate function creates a private heap object from which the
calling process can allocate memory blocks by using the HeapAlloc function.
HeapCreate specifies both an initial size and a maximum size for the heap.
The initial size determines the number of committed, read/write pages
initially allocated for the heap. The maximum size determines the total
number of reserved pages. These pages create a contiguous block in the
virtual address space of a process into which the heap can grow. Additional
pages are automatically committed from this reserved space if requests by
HeapAlloc exceed the current size of committed pages, assuming that the
physical storage for it is available. Once the pages are committed, they are
not decommitted until the process is terminated or until the heap is
destroyed by calling the HeapDestroy function."

I don't know if the CLR uses HeapCreate or not, but almost all Windows
programs do.

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet clr

dotnet clr : virtual memory leak? in asp.net app - OutOfMemory exception