Troubleshooting of one of the most iterating errors when the system is reporting an Out Of Memory Exception.
High memory usage caused by connection static events in dynamic pagesTroubleshoot
Examine the processes
Open the task manager or
process explorer, and look at the private bytes of the process (w3wp.exe for an ASP.NET installation) if that always increases and the process throws an out of memory exception you can continue trouble shoot with this guide.
Conclusion: The process has a memory issue!
Take a closer look at the process using PerfMon
Open
PerfMon and close all existing counters, add the counters
"Process->Private bytes", ".NET CLR Memory->#Bytes in all heap" and ".NET CLR Loading->Bytes in loader heap".
If the counter "Process->Private bytes" increases linear to ".NET CLR Memory->#Bytes in all heap" + ".NET CLR Loading->Bytes in loader heap" the problem is a managed memory issue.
If only the private bytes increases there is a native heap issue and is not going to be written about in this note.
Conclusion: The process has a memory issue in managed code.
Loader heap issue
If only the counter ".NET CLR Loading->Bytes in loader heap" increases – we have a loader problem in managed code.
Add the counter ".NET CLR Loading->Current assemblies" if the numbers of assemblies are extremely high there can be several reasons:
1) The most common for ASP.NET applications – the application is running in debug mode.
Solution: Set the <compilation debug="false"... in your web.cnfig file
2) Using of the constructors for the XmlSerializer (except XmlSerializer(type) and XmlSerializer(type, defaultnamespace)) creates an assembly and should be used with caution.
3) To be written…
Finalizer queue issue
The most common issue I have seen on EPiServer sites is that the finalizer queue is blocked and the CLR has a
Enormous finalizer queue - When the finalizer queue is blocked an out of memory exception is thrown.
Cache issue
The runtime cache in ASP.NET is based on a timer that with calculate the size of memory the cache should have according to the memory allocated of the system and how much memory that was allocated sense the last time the calculation ´was done. So when an out of memory exception is thrown a few cache objects are still in the cache, but don’t care about those.
There was a issue with the cache in .NET 1.1 – the timer doesn’t interrupt when the CPU load was high, but that is fixed and I haven’t had any issues with the cache sense then.
Tips: Don’t use CacheItemPriority.NotRemoveable if you want to avoid out of memory exceptions. Is better that the application recreates the cached objects instead of on out of memory exception.
To examine the cache using windbg you can use the commend
!dumpaspnetcache
Managed heap issue
A common scenario when the system has memory left but it throws an out of memory exception is when you have a
fragmented large object heap. The system thinks it has memory but can’t find a segment large enough to store the new object in.