[Zope] Zope memory usage out of control

Ron Bickers rbickers@logicetc.com
Tue, 6 Feb 2001 01:03:28 -0500


You know what Chris... I'm glad you mentioned this.  I just put 2 and 2
together and may have finally gotten 4.

I have been testing with 3 different objects: Image, ExtImage, and Photo
(http://www.zope.org/Members/Drew/Photo).  Here is what I observed:

* Zope serving 50 different ExtImage objects of 340k each resulted in no
significant increase in memory use (<1MB).

* Zope serving 50 different Image objects of 340k each resulted in ~15MB
memory increase.  Continuing to serve more Image objects that have not
already been served did not result in a further increase.

* Zope serving the preview display of 50 different Photo objects (340k
original size) resulted in ~35MB memory increase.  Continuing to serve more
Photo objects made Zope's memory use continue climbing.  It remained the
same for days as long as no unviewed Photo objects were viewed.  Viewing
different display sizes of Photos already viewed did not increase memory
use.

After finally studying the Photo code, I discovered that the different sized
images are each stored as object attributes (strings using StringIO), not as
separate Image objects.  So each object has about 6 different strings, each
the length of the image of that display size.

It seems that this type of object would cause Zope to eat my memory.  Can
someone verify that this would do it?  I'll be a happy camper if this is the
problem.  I can change the Photo product to store them as Image objects and
hopefully get my memory back.

_______________________

Ron Bickers
Logic Etc, Inc.
rbickers@logicetc.com


> -----Original Message-----
> From: Chris McDonough [mailto:chrism@digicool.com]
> Sent: Monday, February 05, 2001 10:42 PM
> To: Ron Bickers; Navindra Umanee; zope@zope.org
> Subject: Re: [Zope] Zope memory usage out of control
>
>
> Ron, it would be good if you could add a feature request to the Collector
> about large file object streaming.  I'm not superfamiliar with the code
> there, but I *think* the Image stuff is supposed to break the Image object
> into smaller subobjects and load each one serially out of the ZODB when it
> needs to serve them.  If it's not doing this properly, it needs to get
> fixed.