[Zope-dev] Very severe memory leak

[Shane Hathaway]

Leonardo Rochael Almeida wrote:
> Let's assume we're not hitting a 2.6 bug. we could be hitting a 2.6
> feature :-) I've read Casey's article about optimizing ZCatalog and I
> know there has been a lot of ZCatalog optimization work. Has there been
> any changes in 2.6 (in ZCatalog or thread cache or anywhere else) that
> was a tradeoff of memory for speed?

Not that I know of.  To the contrary, I think--we sometimes can't do an 
optimization because it would consume extra memory.

> You mean that one ZCatalog object is in the cache, and (indirectly)
> attached to it are thousands of DateTimes? Then we have a huge problem.

Why?  Although the catalog manages those DateTime objects, the DateTimes 
are in many ZODB records.

> I was counting on the "objects in cache" parameter to put an upper bound
> in Zope memory consumption, even if this upper bound was a little fuzzy.

In the past, the cache size parameter was very fuzzy.  It was not an 
upper bound.  Now, it is not only an upper bound, it also tends to act 
as a lower bound.  (Note that the cache is still allowed to grow 
indefinitely within the scope of a request, however.)

>> Remove all metadata fields you can. 
>>  If you have index dates, use DateTimeIndexes rather than the standard 
>>indexes.
> 
> 
> Well, this is a classic ZCatalog+ZClass site. Almost all ZClasses are
> CatalogAware and they're all cataloged in the monster ZCatalog named
> "Catalog" in the folder that represents the root of the site (as served
> by Apache) because that's how CatalogAware ZClasses work out of the box
> (I know the catalog name can be changed). It has a huge amount of
> Indexes and Metadata. The client grew the site organically, creating
> ZClasses and hanging them in the same ZCatalog as he was needing them.
> 
> It's gonna take a lot of time to untangle it all and we're working on
> it, but for now we need to deal with the emergency that is the fact tha
> migrating to 2.6.1 put us in the very hot spot of not having a way to
> put an upper bound to Zope memory consumption.

I would characterize it the other way around; there was no way to 
establish a hard boundary until now.  I suggest you reduce the ZODB 
cache size to 2000 (or less) and see if the problem goes away.

>>I find it helpful to simply visit the information ZCatalog is storing 
>>for just one cataloged object.  In the catalog contents view, click one 
>>object.  Look at each field and consider how ZCatalog might misuse that 
>>field for other objects.
> 
> What kind of misuse you have in mind?

Large strings, DateTimes, and mutable objects are all bad for the catalog.

> Anyone know off the top of their head how do I get to the object caches?

app._p_jar._cache will get you started.  It is dictionary-like.

Shane