No memory leak! (was: Re: [Zope] Memory Leak in Session Data Container)

[Dieter Maurer]

Andy Yates wrote at 2006-4-17 16:35 -0500:
> ...
>/Control_Panel/Database/temporary/manage_cacheParameters
>Total number of objects in the database    369885
>Total number of objects in memory from all caches    15341
>Target number of objects in memory per cache    5000
>
>It seems odd to me that the total objects in the db are growing so
>large.

This looks fishy, indeed!

  Somehow, the cleanup code
  of "tempstorage.TemporaryStorage.TemporaryStorage" does not seem
  to work in your installation while it does in mine (Zope 2.8.1
  with some modifications).

>If I understand you correctly a workaround would be to change the number
>of objects per cache from 5000 to something more reasonable.

Only to get down the "total number of objects in memory from all
caches". As I know now (and contrary to my original expectation)
it would not affect the "Total number of objects in the database".
Even if my original expectation were right, the "number in the
database" is far too high to be explained by the cached objects.

>Where is
>this configured
>and what is reasonable?

It moved from the ZODB (configured via the ZMI) to the Zope
configuration file (one of the keys of the "zope_db" section).
I no longer know when this move happened. I think, it was Zope 2.7
(but may be wrong).

> 5, 50, 500.  I do not see an
>item for this in the config file.  

If you expect X sessions, then you may want to keep about the most recent X/4
sessions in the cache (rather than repickling them over and over again).
The exact value depends on your preferences (your balance
for speed versus memory consumption).


To stress it again: your large "number of objects in the database"
is not explained by the objects in the cache.
Something else must be wrong in your installation.
Limiting the ZODB cache size for the "temporary" storage
will not drastically effect your memory consumption.

>Should there be any cache at all on an in-memory temp db?

The cache does not save IO, of course, but unpickling time which
may be considerably as well.

  A recent profile showed:

	   IO			3.9 s
	   Unpickle		1.3 s

  However, it was a singular measurement. You probably cannot generalize
  it.

-- 
Dieter