[Zope] Zope leaking memory?

Jean-Francois.Doyon at CCRS.NRCan.gc.ca Jean-Francois.Doyon at CCRS.NRCan.gc.ca
Mon Sep 13 13:29:04 EDT 2004


That's the good ol' memory leak I was (And still am) suffering from.

I eventually had to capitulate and set up a nightly reboot :(

I'd developped all sorts of inetersting ways to track down what was holding
references, but ran into ExtensionClass'es which made the whole thing overly
complicated.

I'm hoping with Zope 2.8, if the problem still exists, I'll be able to
better track down the source of the problem.

J.F.

-----Original Message-----
From: zope-bounces at zope.org [mailto:zope-bounces at zope.org]On Behalf Of
Chris McDonough
Sent: September 12, 2004 10:49 AM
To: Dennis Allison
Cc: zope at zope.org
Subject: Re: [Zope] Zope leaking memory?


I've noticed what I believe are "request leaks" if any variety of CMF is
involved in a request though I haven't tracked this down.  The symptoms
are that every request causes the HTTPRequest class to have its
reference count increased by one, plus a bunch of other objects are
leaked because the request that was leaked apparently continues to hold
on to references to them.

This may or may not be what you are seeing.

If you want to track something like this down, there is really no
shortcut.  My strategy (which I've never successfully used to actually
fix a leak, mind you! ;-) is this:

- Confirm that bare Zope doesn't leak by testing refcounts before
  and after you load the quickstart page several times (remember
  to clear the ZODB cache before you start hitting the site
  whenever trying to test refcounts).  Look at the number of
  references to all classes in the Debug tab.  These references
  should not normally grow on every request.

- Do same for one of your "domain" objects.

If you see leakage when trying this against a method of one of your
domain objects, a binary-exclusion method is usually the only way to pin
down the leak.  Prevent half of the code that gets run when your domain
object method is called from running.  If you still see the leak, the
leak happens in the code you didn't prevent from running.  If you did,
the leak happens in the code that ran.  And so forth.  It's tedious and
time-consuming, which is probably why I've never successfully used it to
fix a leak. ;-)

- C


On Sun, 2004-09-12 at 01:33, Dennis Allison wrote:
> Pound-current (V 1.7+)
> Zope 2.6.4
> Python 2.3.4
> RH 7.3
> Dual Athalon processors
> 
> Occasionally, I see Zope gathering very large amounts of real memory.
> Normally buffering and the like seems to stabalize at around 500MB on a
> 4GB memory dual processor machine, but occasionally grows to 2.5GB or
> more.  At the same time, CPU usage tends to fully occupy one of the
> processors for the threads holding all the memory.  Clearly there is a
> problem.  Any hints as to where to track down the problem?
> 
>  
> 
> _______________________________________________
> Zope maillist  -  Zope at zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )
> 

_______________________________________________
Zope maillist  -  Zope at zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


More information about the Zope mailing list