In previous post I mentioned “many things have changed – but some haven’t”. SharePoint still uses COM Components for some of its core features. There is nothing wrong with COM, there is with memory management of COM Objects.
SPSite and SPWeb objects are used by developers to gain access to the Content Database. What is not obvious is that these objects have to be explicitly disposed in order for the COM objects to be released from memory once no longer needed.
Problem: SharePoint runs into memory leaks by not disposing SPSite and SPWeb objects. It means ASP.NET Worker Process is leaking memory (native and managed) and will end up being recycled by IIS in case we run out of memory.
Recycling means losing all current user sessions and paying a performance penalty for those users that hit the worker process again after recycling is finished.
Solution: Need to monitor memory usage to identify whether you have a memory leak or not. Use a memory profiler to identify which objects are leaking and what is creating them.
You should follow Best Practices as described on MSDN for SPSite and SPWeb objects.
Microsoft also provides a tool to identify leaking SPSite and SPWeb objects called SPDisposeCheck