[Zope] Controlling caching of objects
tdickenson at geminidataloggers.com
Wed Oct 22 05:59:49 EDT 2003
(I trimmed the crossposts)
On Wednesday 22 October 2003 09:05, Bjorn Stabell wrote:
> In Zope 2.6.2 it's quite easy to put an upper limit on the number of
> objects in memory per thread. But does this mean that Zope won't swap
> out objects until it reaches that limit?
The right term is "deactivate". The main reason for deactivating an object is
that the total number of objects exceeds the per-thread limit. There are
> It looks like this:
> Target # of objects per thread: 20,000
> Actual # of objects per thread: ~15,000
> Actual # of ghost objects per thread: ~43,000
> Were the ghost objects once loaded in memory and then swapped out?
No. Ghost objects are those that need a small (100 byte approx) stub in memory
because there is an active object that has a reference to it. The difference
between a ghost (stub) and a full object is that the ghost object does not
have all its attributes loaded into memory. It does has its oid in memory
though, so it can ask the storage to load those attributes on demand. This is
Note that if one of those attributes is a reference to another persistent
object (for example, think of folders), then activation will trigger the
creation of a ghost for each referenced object.
Ghosts are removed from memory based on reference counting, and is the inverse
of the process described in the previous paragraph.
> I find the current system of controlling # of objects in memory per
> thread to be a bit difficult to use. Most people, I think, would prefer
> to put an upper limit on the total MB of memory Zope uses instead. Are,
> what are the cons/pros?
pro: it would be much better.
con: it hasnt been done yet.
The current system is much better than in versions before 2.6. Noone has found
the current system bad enough to give it the effort needed for improvement.
Patches gratefully accepted.
More information about the Zope