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