RE: [Zope] Zope Eating Memory for Breakfast
--- In zope@egroups.com, Chris McDonough <chrism@d...> wrote:
Both of you seem to be using Sybase DAv2, for which there was a known memory leak. The latest release got rid of it. Are you running the latest releases, respectively?
That was my fear at first. But I am using the latest version (SybaseDA-2.0b2), so that's not the problem. As I have pointed out in another message, the memory leak is from some of the Zope's management methods. One of the symptoms is that when you do a "Find", the memory usage does not go back down to where it was before. (It does goes up and then down, just not to the original point.) Now the thing to do is to pinpoint the Zope method that is causing the memory leak. (I don't want to mislead people into thinking that "Find" is the thing causing memory leak... it's not. It's a symptom, not a cause. The memory also goes up in other Zope management operations, but I still need to pinpoint which operations.) regards, Hung Jung ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
Hung Jung Lu wrote:
--- In zope@egroups.com, Chris McDonough <chrism@d...> wrote:
Both of you seem to be using Sybase DAv2, for which there was a known memory leak. The latest release got rid of it. Are you running the latest releases, respectively?
That was my fear at first. But I am using the latest version (SybaseDA-2.0b2), so that's not the problem.
As I have pointed out in another message, the memory leak is from some of the Zope's management methods. One of the symptoms is that when you do a "Find", the memory usage does not go back down to where it was before. (It does goes up and then down, just not to the original point.) Now the
What are you using (precisely) to determine this? What is the difference in prior-find memory use (if on linux: active, buffers, cache and shared, please). Remember that Linux (and a few other *nixes, ISTR) will store some of the memory in buffers/caches to keep recently or frequently accessed 'things' readily available. I am curious because I am implementing a rather important (aren't they all?), large-scale Zope Portal App, and this kind of information is crucial. -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
Hung Jung Lu wrote:
As I have pointed out in another message, the memory leak is from some of the Zope's management methods. One of the symptoms is that when you do a "Find", the memory usage does not go back down to where it was before.
This is normal behavior, a Find can potentially activate many objects, especially if you use an expression, when the find is done, the object cache is now full. Before you start the Find, there is a good chance that the object cache wasn't full. After a certain period of time, idle objects will get deactivated from the object cache.
(It does goes up and then down, just not to the original point.) Now the thing to do is to pinpoint the Zope method that is causing the memory leak.
*If* there is one. I'm not convinced that there is.
(I don't want to mislead people into thinking that "Find" is the thing causing memory leak... it's not. It's a symptom, not a cause. The memory also goes up in other Zope management operations, but I still need to pinpoint which operations.)
Control_Panel/manage_debug will give your refcounts for all objects in Zope. This is the best place to spot potential memory leaks. -Michel
Michel Pelletier wrote:
Control_Panel/manage_debug will give your refcounts for all objects in Zope. This is the best place to spot potential memory leaks.
Well, I for one have 4000 references to webdav.xml.Text and .Element. We run a webdav client every hour to download stuff, but it runs off the same set of objects each time, and the refcount has _doubled_ from 2000 since the last time I checked today. 'Course, I know nothing about Python internals - any idea why it might double? It somply checks the same set of files every time to see if they've changed. And of course I seem to have a leak in freetype, but that one's documented :) -- Itamar S.T. itamars@ibm.net
participants (4)
-
Bill Anderson -
Hung Jung Lu -
Itamar Shtull-Trauring -
Michel Pelletier