[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