Hi, It's me and my instability problems again :-) The system: Zope-2.4.4b1 (binary linux-x86 from zope.org) Python-2.1.2 (see above) Products (excluding Zope defaults and ZClass based ones): LocalFS Pagina0_Base (Hiperlógica product) Pagina1_Base (Hiperlógica product) Renderable exUserFolder It has an 800+MiB Data.fs (when packed) that is crammed full of python scripts. I'm still looking for a way to recompile them all without sending the machine (1GiB physical RAM) into a swap storm which would ultimately crash Zope or the machine and keep it from commiting the transaction that caused all the trouble in the first place (one of these days I'll refactor the subtransaction code out of the ZCatalog and into a ZopeFind that will accept an action parameter, along with a subtransaction one, to perform these kinds of global maintenance in a reasonable way). None of the products mentioned above use C compiled modules. I disabled all the use of mysql on this instance so that I could remove ZMySQLDA and faked the authentication system so that it's usage pattern remained the same even without mysql. After that I reenabled the cycle-gc. The system started crashing about every 5 minutes. As much as I'd have liked pointing a finger at ZMySQLDA, start the process of migration to PostgreSQL and consider this problem solved once and for all, I have finally come to the conclusion that there is no one else to blame but Zope and Python themselves. I have since reenabled ZMySQLDA use by the site and disabled the cycle-gc. The options I think I have left: * Try the new ExtensionClass.h * Run Zope under a memory analiser such as Valgrind (which might not be feasible if the runtimes are too slow): http://devel-home.kde.org/~sewardj/ * Try migrating to Zope-2.5.1b1 The situation is starting to look desperate. We now have to restart the server twice a day to keep the machine from swapping. This can't go on any longer. Any suggestion is apreciated. -- Ideas don't stay in some minds very long because they don't like solitary confinement.