CODEWITHSUNDEEP
asp.net.netasp.net-mvc
Adam
Adam

Reputation: 4227

ASP.NET Memory Leak Strange Charts

I am trying to diagnose a memory leak, and I'm getting some strange numbers, perhaps someone can point out why I'm seeing what I'm seeing.

The first step that I performed, was attempting to see where the leak was occurring, in managed or unmanaged space.

I profiled the process, and got the following chart

enter image description here

According to the various documentation on leak diagnostics, I should see either, the private bytes run away while the "all heaps" don't (indicating an unmanaged leak) or they both run away in parallel, indicating a managed one.

It appears I do have a leak - (chart is CPU+Private Bytes+Managed Heaps).

What is puzzling me - is - why do my managed heaps consume only about 30MB between 9am and just before 5pm (but private bytes grow), then all of a sudden - BOOM my managed heaps jump to 3 gigs consumed?

Why would this happen?

UPDATE:

654cf3d8   199671      6389472 System.Web.HttpCacheValidateHandler
719c25e8   559507      6714084 System.Object
654b82e8    95499      6875928 System.Web.HttpServerVarsCollection
05e90a24   253641      7101948 System.Web.Mvc.NameValueCollectionValueProvider+ValueProviderResultPlaceholder+<>c__DisplayClass8
654e42e4    97208      7776640 System.Web.HttpWriter
04c2a5c8   264802      8473664 Castle.MicroKernel.BurdenReleaseDelegate
04c2ab68   264813      9533268 Castle.MicroKernel.Burden
06bde0a8   507282     10145640 System.Lazy`1[[System.Web.Mvc.ValueProviderResult, System.Web.Mvc]]
6fb5348c   267697     10707880 System.Collections.Generic.HashSet`1[[System.String, mscorlib]]
654e9388   160209     11535048 System.Web.HttpHeaderCollection
654ad44c   194416     12442624 System.Web.HttpCookieCollection
6fd1abbc   170480     14202840 System.Collections.Generic.HashSet`1+Slot[[System.String, mscorlib]][]
654b2204    95203     15613292 System.Web.HttpCachePolicy
06bde010   507282     16233024 System.Func`1[[System.Web.Mvc.ValueProviderResult, System.Web.Mvc]]
719c3a6c   469961     18106904 System.Int32[]
654e87e4    97208     18275104 System.Web.Hosting.IIS7WorkerRequest
654e2590    97208     19441600 System.Web.HttpRequest
654e285c    97208     19830432 System.Web.HttpResponse
715fbc80   422170     20264160 System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[System.Object, mscorlib]]
654e2160    97208     23329920 System.Web.HttpContext
654e9614   388836     23330160 System.Web.HttpValueCollection
719c45c8   919071     47791692 System.Collections.Hashtable
654d5220  4808083    115393992 System.Web.HttpServerVarsCollectionEntry
719bfc20  4849839    116396136 System.Collections.ArrayList
719c4584   105080    119191278 System.Byte[]
70d45bec  9064979    145039664 System.Collections.Specialized.NameObjectCollectionBase+NameObjectEntry
719afe88  5391401    175028320 System.Object[]
719c5ed4   919078    237147240 System.Collections.Hashtable+bucket[]
719c2248  7055089    454532758 System.String

Ok, so I've run windbg over the crash dump, (!dumpheap -live -stat) and I've found that there are LOT of objects relating to the Http context, which are still held in memory (98,000 after a typical work day in fact).

Can anyone confirm... I shouldn't be seeing this right? There are Types occurring 97,208 times in the log - This means that the HttpRequest/HttpResponse, etc are being held in memory, causing ALOT of leakage. What could be causing this? I know they're not being stored in the session..my session is set to default timeout, and when inspecting, it only contains 3 small string objects.

Upvotes: 2

Views: 675

Answers (1)

Adam
Adam

Reputation: 4227

Figured it out. Running GCroot highlighted the problem. See how there is a Castle.MicroKernel.Releasers.LifecycledComponentsReleasePolicy in the reference list?

Castle wasn't being told to release the controller after the request had completed. Mystery solved.

0:000> !gcroot 95963d2c
HandleTable:
    00bb12f0 (pinned handle)
    -> 03062490 System.Object[]
    -> 021501dc Castle.Windsor.WindsorContainer
    -> 02150200 Castle.MicroKernel.DefaultKernel
    -> 02150304 System.Collections.Generic.Dictionary`2[[System.String, mscorlib],[Castle.MicroKernel.ISubSystem, Castle.Windsor]]
    -> 02150af8 System.Collections.Generic.Dictionary`2+Entry[[System.String, mscorlib],[Castle.MicroKernel.ISubSystem, Castle.Windsor]][]
    -> 02150b74 Castle.Windsor.Diagnostics.DefaultDiagnosticsSubSystem
    -> 02150b8c System.Collections.Generic.List`1[[Castle.Windsor.Diagnostics.IContainerDebuggerExtension, Castle.Windsor]]
    -> 02150d00 System.Object[]
    -> 02150d30 Castle.Windsor.Diagnostics.Extensions.ReleasePolicyTrackedObjects
    -> 02150d3c Castle.Windsor.Diagnostics.TrackedComponentsDiagnostic
    -> 02150e04 System.EventHandler`1[[Castle.Windsor.Diagnostics.TrackedInstancesEventArgs, Castle.Windsor]]
    -> 02150d54 Castle.MicroKernel.Releasers.LifecycledComponentsReleasePolicy
    -> 02150d84 System.Collections.Generic.Dictionary`2[[System.Object, mscorlib],[Castle.MicroKernel.Burden, Castle.Windsor]]
    -> 038da530 System.Collections.Generic.Dictionary`2+Entry[[System.Object, mscorlib],[Castle.MicroKernel.Burden, Castle.Windsor]][]
    -> 9596f3a4 WebController
    -> 9596f9cc System.Web.Mvc.ControllerContext
    -> 95965b5c System.Web.HttpContextWrapper
    -> 95964078 System.Web.HttpContext
    -> 95963d2c System.Web.Hosting.IIS7WorkerRequest

Upvotes: 1

Related Questions