ASP.Net: Finding the cause of OutOfMemoryExpcetions

I trying to track down the cause of an OutOfMemory for a website. This site has ~12,000 .aspx pages and the last time it crashed I captured a memory dump using adplus.

After some investigation I found a lot of heap fragmentation, there are around 100MB of Free blocks which can't be assigned. Digging deeper one of the Large Object Heaps is fragmented and the causes seems to be String interning as described [here][1]

Could this be caused by the number of pages in the site? As they are all compiled they sit in memory and by looking at the dump they are interned and PINNED which I think means they stick around for a while.

I would find this odd as there are many sites with more pages, but dynamic compilation could account for the growth in memory.

What other methods are there for finding the cause of the memory leak? I have tried to capture a dump using adplus 开发者_如何学JAVAin hang mode but this fails and the IIS worker process get recycled.

[1]: • Large Object Heap Fragmentation

---

Yep fragmentation is one of the reason because it will be more difficult to 'find' memory.

Some very known clues :

• On a 32bit OS, your worker process can't exceed 2 GB in memory even if your system have more. An alternative is the /3GB switch (boot.ini file).

• The likelihood of experiencing an OutOfMemoryException begins to increase dramatically when “Process\Virtual Bytes” is within 600 MB of the virtual address space limit (generally 2 GB), and secondly, tests have shown that “Process\Virtual Bytes” is often larger than “Process\Private Bytes” by no more than 600 MB

• The CLR is allocating and handling the memory by blocks (64 MB from memory;)). It does not mean it use all this memory, it means one block will not be freed until one byte is used and it's how the memory become fragmented.

• When the CLR can't allocate memory (new block needed), and it can't garbage collect or page some of the memory, OutOfMemoryException is going to happen in the best case or the server will be overloaded in the worst case.

• About dynamic compilation, that's true but the most important is the <compilation debug="false" /> / <deployment retail=”true”/> switches. They turn on batch compilation which mean one DLL by directory (this is another point) and not one DLL per 'page' which cause virtual space fragmentation.

• About one DLL by directory, even with batch compilation, more directories/sub-directories you have, more DLL you will have and more fragmented virtual address space you will have.

Personally, I use ANTS Memory Profiler to find memory issues.

---

There is a really good blog here by Tess Ferrandez that talks about memory issues and other types of debugging issues while developing ASP.NET applications.

One post in particular walks you through a tutorial to see if you have a leak. Its uses the nasty WinDBG, but she explains all the commands so you can get a clear picture of your used memory and it shows you exactly which objects are filling all the space.

I have used her site many times to diagnose memory leaks and other performance related problems.

I have also used tools like DebugDiag to help capture memory related issues and used its built in diagnostic tools to help find the problems.