Andy Yates wrote at 2005-1-3 13:49 -0600:
... After flushing main and temporary ... OK so the numbers are small. This means there is no leak right?
Right -- at least not the usually leaks. The reference count list shows you only reference counts for instances (and not elementary types). You might build leaking cycles consisting only of elementary types -- but this is quite unlikely. Also, Python never releases integer objects it has constructed. Thus, once you iterated from 0 to 4 G, you have several GB of integer objects -- but it is unlikely that you do this...
It may not be leaking, but python still consumes all available memory and dies unless I restart Zope every few days. ;-)
You did this flushing and looking at the reference counts in a process that already had run for several days (and therefore was quite huge)? Do you use C extensions that create non-Python objects (and therefore do not have reference counts and show up in the list)? Maybe, such a C extension is leaking. There are tools to analyse memory leaks (and other memory related problems). Once, I have use the (commercial and expensive!) "purify". Andreas (Jung) told me that there are free open source tools for this purpose around. Unfortunately, I forgot the details (I only create standard leaks :-)
... Maximum number of subobjects is infinite (0) Data object timeout is 45 minutes
Are your sessions huge? Usually, they are stored as pickles in RAM. If they were huge, some thousands of sessions might consume a considerable amount of RAM. You would not see them in the reference counts because Pickles are strings and you see only instances. -- Dieter