> After some time of running it seems that my process has a lot of
> ZEO.cache.Entry objects around... sys.getrefcount reports a huge number
> of references
To what was sys.getrefcount() applied? Which version of Python are you
> (155989 when I only have 625 object references!). I've run
> a memory profiler on my code which shows the number of objects of class
> ZEO.cache.Entry (along with tuple and list) always increasing. This
> happens even when I set the cache to a small value (eg. 32k).
Sounds like a bug, then, "somewhere". I expect the maximum # of Entry
instances to be proportional to the cache size.
> The only place I could find a similar report is in
> http://www.zope.org/Collectors/Zope/1847 comment #7 where someone else
> reported similarly high refcounts for ZEO.cache.Entry last month.
> Is it normal to have an (apparently) unbounded increase in these objects?
> Or maybe theres some cleaning mechanism and I just haven't run the
> process long enough?
Cyclic gc runs at unpredictable times. You can force a collection via
but Entry instances aren't involved in cycles, so I doubt that will matter.
> Or maybe a bug?
That's my best guess. If you have (or can create) a small, self-contained
script showing the problem, that would be the most effective way to make
progress. I've run stress tests against the ZEO cache that have run for
days without provoking noteworthy memory loss, so it's apparently not
something that can be provoked by any old ZEO code.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org