[IronPython] IronPython with CherryPy through WSGI Memory issue

Dino Viehland dinov at microsoft.com
Thu Apr 1 15:46:19 PDT 2010


> On Thu, Apr 1, 2010 at 4:17 PM, Can Gencer <cgencer at gmail.com> wrote:
> > On Thu, Apr 1, 2010 at 7:27 PM, Dino Viehland <dinov at microsoft.com> wrote:
> > I tried this, ExceptionHelpers.DynamicStackFrames.Count seems to be
> > constant at 1.. I'm not very familiar with windbg but I can certainly
> > learn more about it.. What should I be looking for?
> 
> You could try running it under CLRProfiler:
> 
> http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-
> 8926-862b40aa0cd0&DisplayLang=en
> 
> http://msdn.microsoft.com/en-us/library/ms979205.aspx
> 
> With it you can see which objects stick around after a GC, what's
> holding those objects, and where they're allocated. I'm not too
> familiar with its use yet, but I plan on doing that tomorrow.

Yeah CLRProfiler is a little more friendly :)  I like windbg because it gives
reasonable way of tracking who's keeping what alive and I find it a little more
reliable than CLRProfiler.  What I usually do is attach to the process after
letting it leak for a while and then:

.loadby sos mscorwks
	Or
.loadbys sos clr

For CLR v2 and CLR v4 respectively.  Then you can do:

!DumpHeap -stat

Run for a while, repeat that, and look at what types of objects are growing. 
They should be at the end of the list because after running for a while they're
growing the most.  Then you can do:

!DumpHeap -mt <method_table>

Where <method_table> is the address for the type that !DumpHeap -stat gave you.

Then you can start picking objects at random and do:

!GCRoot <object_addr>

And you see who's keeping it alive.

If the leaks big the places to look at pretty obvious.  If it's leaking Python 
objects defined in classes though you'll see those as "Unloaded Type".




More information about the Users mailing list