Python/Zope + Alpha/Redhat == Memory Bloat?
I am observing the following phenomenon: Develop a Zope site on Intel/Redhat. Takes about 40MB RAM. Deploy the site on Alpha/Redhat. Contantly grows, easily eating 1GB (!) of RAM until it hits the swap and we restart Zope! All this with the same versions of Python/Zope/Products on Intel and Alpha. I see that with all Zopes (2.3.0-2.4.3) and all Pythons (1.5.2-2.1.2) in all our Projects (and quite different they are). My admins are out of ideas, say they tried everything (different compilers, gcc alpha patches, ...). We also tested Tru64 but could't even get Python going well (lockups, segfaults, out-of-memory conditions). Anybody successfully - that is without obscene memory consumption - running Python/Zope on Alpha processors? Grateful-for-even-the-smallest-hint-ly yours, Stefan
Stefan H. Holek wrote:
I am observing the following phenomenon:
Develop a Zope site on Intel/Redhat. Takes about 40MB RAM. Deploy the site on Alpha/Redhat. Contantly grows, easily eating 1GB (!) of RAM until it hits the swap and we restart Zope!
I assume you've removed extra products and you're running an "out of the box" Zope. The first thing I would look at is the "debugging" control panel. It will tell you if there are a lot of instances of specific Python classes. If there are, it could be a Zope bug. If there aren't, it's probably a Python (or C runtime or C compiler or kernel or hardware ;-) ) bug. Shane
At 31.01.2002 13:01 -0500, Shane Hathaway wrote:
Stefan H. Holek wrote:
I am observing the following phenomenon: Develop a Zope site on Intel/Redhat. Takes about 40MB RAM. Deploy the site on Alpha/Redhat. Contantly grows, easily eating 1GB (!) of RAM until it hits the swap and we restart Zope!
I assume you've removed extra products and you're running an "out of the box" Zope.
The first thing I would look at is the "debugging" control panel. It will tell you if there are a lot of instances of specific Python classes. If there are, it could be a Zope bug. If there aren't, it's probably a Python (or C runtime or C compiler or kernel or hardware ;-) ) bug.
Shane
How does for example RestrictedPython.compiler.transfomer.Transformer: 774635 look to you? ;-) Seriously, I am seeing this over all our projects with various versions of Zope and Python on Alpha/Redhat. In one project it's the BTrees, in another it's RestrictedPython. I assume it to be a Python GC problem on that particular combination, because, as I said, the very same things on Intel work perfectly. So, anybody else seeing this? Anybody out there running Zope on Alpha/Redhat? How do you do it? Any success stories with Alpha/Debian maybe? I'd rather find a solution than tell a bunch of customers they need new hardware :-/. Thanks, Stefan
Stefan H. Holek wrote:
At 31.01.2002 13:01 -0500, Shane Hathaway wrote:
Stefan H. Holek wrote:
I am observing the following phenomenon: Develop a Zope site on Intel/Redhat. Takes about 40MB RAM. Deploy the site on Alpha/Redhat. Contantly grows, easily eating 1GB (!) of RAM until it hits the swap and we restart Zope!
I assume you've removed extra products and you're running an "out of the box" Zope.
The first thing I would look at is the "debugging" control panel. It will tell you if there are a lot of instances of specific Python classes. If there are, it could be a Zope bug. If there aren't, it's probably a Python (or C runtime or C compiler or kernel or hardware ;-) ) bug.
Shane
How does for example RestrictedPython.compiler.transfomer.Transformer: 774635 look to you? ;-)
Very excessive! The compiler package (contained in RestrictedPython, but as of Python 2.2 it's in the Python standard library) uses a lot of circular references. If circular GC isn't working then every time you use a Python script, Page template expression, or a DTML expression, memory bloat will follow. I wonder if you should approach this by fixing Python's circular GC or by fixing the circular references in the compiler package. Since there could be other circular references, the first option seems better. Shane
participants (2)
-
Shane Hathaway -
Stefan H. Holek