[Zope] Controlling caching of objects

Toby Dickenson tdickenson at geminidataloggers.com
Thu Oct 23 07:00:38 EDT 2003


On Thursday 23 October 2003 11:46, Bjorn Stabell wrote:

> After restart + 1 minutes (1-2 accesses that does 1-2 catalog queries
> each) it's at 9,870 objects (total) using 130 MB of RAM, giving 13.1 kB
> per object.  I've got profiling and debugging on now.  From experience,
> it's varied from 8 kB to 13 kB per object.
>
> Okay, so what are these objects:
>
> CONTROL PANEL / DEBUGGING PAGE
> Top Refcounts:
> 	DateTime.DateTime.DateTime: 59530
> 	BTrees._IIBTree.IISet: 4002
> 	BTrees._IOBTree.IOBucket: 2573
> 	RestrictedPython.compiler_2_1.misc.Set: 2308
> 	AccessControl.User.User: 1632
> 	Products.CMFCore.MemberDataTool.MemberData: 1628
> 	BTrees.OOBTree.OOBucket: 1469
> 	Persistence.PersistenceMapping: 1331
> 	[...]
> 	OFS.Image.Image: 692
> 	[...]
> 	App.ImageFile.ImageFile: 319
> 	[...]
>
> The Cache Detail page corresponds to 

"Cache Extreme Detail" is the page to study (although it is too big to post 
here). Look at what objects are live in each connection.

> the Top Refcounts,

That page is good for tracking down memory leaks, but not so good for 
analysing cache behaviour. For example, I cant tell whether those 1628 member 
objects exist as ghosts (good) or activated objects (bad).

4000

>  but doesn't list
> many classes, such as DateTime.DateTime.DateTime?

They are not individual persistent objects, so they dont get their own slot in 
the cache.


-- 
Toby Dickenson




More information about the Zope mailing list