> A question and one remark.
> Wouldn't staring at the refcounts in the debug panel also give some
> info? At least for selfmade products?

Maybe... depends on your level of Zope Zen.  It's hard to tell which classes
should and should not have high refcounts.  For example, in your sample
output, I know that high numbers of references to ImplicitAcquirerWrappers,
HTTPRequests, ZServerHTTPResponse, and RequestContainer objects likely
indicate a leak of REQUEST objects somewhere in your code.  OTOH, the high
number of references to DTMLMethods might be totally normal.  But I only
know these things because I know Zope maybe better than most folks do, and I
just...  well... *know*.  ;-)  It's hard to explain the reasons I know these
things to other folks (although I started on something like it at

That said, even if I took a day to finish my unfinished HowTo, the only bit
of wisdom that I could consistently espouse given Control_Panel -> Debug
output is that indeed you do have a leak.  So you'd know you have a leak
(which you knew in the first place).  How do you fix it?  I don't know. ;-)
That's where the binary search comes in.  Shane's LeakFinder can make the
binary search a bit easier by recording states between leakfinding runs, but
it's still mainly an exercise in binary search.

> The remark, Andre, Chris has written a very nice product, called
> AutoLance which helps by monitoring zope's memory usage and restarting
> if a configurable threshold is reached.

If you can't solve the problem at least treat the symptoms. ;-)

- C

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to