Have Geek Brain

ASP.Net: Finding Cause of OutOfMemoryExpcetions

I am trying to find the reason for the OutOfMemory for a website. This site has ~ 12,000 .aspx pages and it crashed last time. I captured a memory dump using adplus.

After some research, I found a lot of heap fragmentation, there are about 100MB of free blocks that cannot be assigned. Digging deeper than one of the LOB heap is fragmented and the reasons seem to be line interpolation as described [here] [1]

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

I would find it odd as there are many sites with a lot of pages, but dynamic compilation can explain the growth in memory.

What other methods are there for finding the cause of a memory leak? I tried to grab a dump using adplus in hover mode, but that fails and the IIS worker process is recycled.

[1]: LOB Heap Fragmentation

+2


a source to share


2 answers


Explicit fragmentation is one of the reasons because it will be harder to "find" the memory.

Some very famous tips:



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

  • The likelihood of an OutOfMemoryException being thrown sharply increases when "Process \ Virtual Bytes" is within 600 MB of the virtual address space limit (usually 2 GB), and second, tests show that "Process \ Virtual Bytes" is often larger than " Process \ Private Bytes "no more than 600 MB

  • The CLR allocates and processes memory in chunks (64 MB of memory;)). This does not mean that it uses all this memory, it means that one block will not be freed until one byte has been used, and as memory fragmentation.

  • When the CLR is unable to allocate memory (a new block is required) and it cannot collect or collect garbage or any piece of memory, an OutOfMemoryException will occur at best, or the server will be overwhelmed in the worst case.

  • As far as dynamic compilation is concerned, this is true, but the most important are the <compilation debug="false" />

    / switches <deployment retail="true"/>

    . They involve batch compilation, which means one DLL per directory (that's another point), not one DLL per "page" which causes virtual space fragmentation.

  • About one DLL per directory, even with batch compilation, more directories / subdirectories you have, more DLLs you will have and the more fragmented virtual address space you will have.

Personally, I use ANTI Memory Profiler to find memory problems.

0


a source


There is a really nice blog here from Tess Ferrandes that talks about memory issues and other types of debugging problems when developing ASP.NET applications.

One post in particular you are looking at a tutorial to see if you have a leak. It uses the nasty WinDBG, but it explains all the commands so you can get a clear idea of ​​your memory usage and it shows you exactly which objects are filling all the space.



I have used my site many times to diagnose memory leaks and other performance related issues.

I've also used tools like DebugDiag to help with memory-related issues and use built-in diagnostics to find problems.

0


a source






More articles:


All Articles