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 )