Dylan Jay wrote at 2005-5-13 14:01 +1000:
>Just in case anyone can shed anymore light on zope memory woes, here is 
>where I've got to in my investigation:
>
>- Memory grows and mostly doesn't shrink.

That's normal behavior.

>- Its not due to objects that can't be collected by the GC
>- Its not due to the ZODB cache
>
>That leaves the following causes I think
>- RAMCache etc and module/class variables. Either mine, plone's or zope's.

When I remember right, then also the reference counts do not
go up.

In this case, the leak must be caused by elementary Python types
(more precisely by objects the type of with is statically
allocated) -- if Python objects cause the leak at all.

>- Pythons design of not releasing memory from small objects back to the OS
>http://www.sauria.com/~twl/conferences/pycon2005/20050325/Improving%20Python's%20Memory%20Allocator.html

Python has no big chance. The memory management options of the
underlaying operating systems are quite limited and Python
uses the C memory management at its lowest level.
Thus, it must live with what "C" provides.

>   Has anyone tried to determine how much of an average catalog search is 
><256kb?

What is an "average" catalog search?
How do you measure the size of a catalog search?

>- Some other kind of reference being help somewhere in the zope machinery.

Did I not tell you about a special Python build to
analyse memory leaks?

-- 
Dieter
_______________________________________________
Zope maillist  -  Zope@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 )

Reply via email to