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 http://www.zope.org/Members/mcdonc/HowTos/PreventAndDebugMemLeaks (unfinished). 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