RE: [Zope] Controlling caching of objects
From: Toby Dickenson [mailto:tdickenson@geminidataloggers.com]
Is that an assumption, or measurement?.... there are several useful pages in control panel.
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 the Top Refcounts, but doesn't list many classes, such as DateTime.DateTime.DateTime? Hm, that's about all I can find out. Does this look strange? The application running on the site, by the way, is a BBS-type application with a few thousand messages imported from another system. Regards, -- Bjorn
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
participants (2)
-
Bjorn Stabell -
Toby Dickenson