Shane Hathaway writes:
Jason Spisak wrote:
Shane Hathaway writes:
Jason Spisak wrote:
You must have a large site.
300,000 + objects
Whoa... ;-)
Tell me, what are you doing with 300K objects?
Shane
Technical recruiting. I am the ultimate test case for ZDOB scalability. ;)
I just recently started having problems thoug, so I am going back and disabling the small fixes I have made recently in my code.
I just restarted Zope again.
Most of the objects just sit around.
Wow. There it goes again. It's got to be DateTime.DateTime.DateTime. It just shot to 118003.
That's actually a natural thing to happen. DateTime objects get attached to many kinds of objects. The real problem is that so many objects are being loaded into memory.
I just did some research and it looks as though garbage collection is not fully implemented in Python. I was not aware of this; do you know whether it has been corrected?
No, I had no idea.
After minimizing your in-memory cache, look at the manage_debug screen again. Are the refcounts still high? I bet they are...
No. The ref counts drop to hundreds. Also, is see reference to 161 Products.GadflyDA.gadfly.kjparser.ParseRule, and I'm not even useing Gadfly! What the heck is that about? Anyone? Thing's seem to be a bit nicer now that I took out an External Method that returns a DateTime object the Catalog for Indexing. However, there's only about 14,000 of objects with that property in existsnce in my DB, and they don't change often. Here's the code: def calendar_day(self) return int(self.calendar_date)/1000000 Used to return the unique integer day. All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Jason Spisak wrote:
After minimizing your in-memory cache, look at the manage_debug screen again. Are the refcounts still high? I bet they are...
No. The ref counts drop to hundreds.
That's a big relief. Okay, now we know that this isn't a memory leak, it's only related to the fact that your site requires ZODB to load a very large number of objects into memory in order to perform normal operations. Here's something to think about: whenever an object is added to or removed from a folder, all objects in all neighboring folders and below are traversed. The manage_beforeDelete and manage_afterAdd hooks are called on each object. Also, there is still the issue that Python doesn't seem to be releasing memory back to the system. I wonder whether that capability has been implemented in Python.
Also, is see reference to 161 Products.GadflyDA.gadfly.kjparser.ParseRule, and I'm not even useing Gadfly!
What the heck is that about? Anyone?
Chances are some other product is "reaching in" to Gadfly. Do you have the Zope tutorial installed? It uses Gadfly.
Thing's seem to be a bit nicer now that I took out an External Method that returns a DateTime object the Catalog for Indexing. However, there's only about 14,000 of objects with that property in existsnce in my DB, and they don't change often.
Here's the code:
def calendar_day(self) return int(self.calendar_date)/1000000
Used to return the unique integer day.
That code actually doesn't return a DateTime instance, just an integer. Keep me informed. Shane
----- Original Message ----- From: "Shane Hathaway" <shane@digicool.com> To: "Jason Spisak" <444@hiretechs.com> Cc: <zope-dev@zope.org> Sent: Monday, May 22, 2000 6:29 PM Subject: Re: [Zope-Dev] Zope 2.1.6 Memory issue
Here's something to think about: whenever an object is added to or removed from a folder, all objects in all neighboring folders and below are traversed. The manage_beforeDelete and manage_afterAdd hooks are called on each object.
Jason, I don't know if you've taken much of a look at ZPatterns yet... Depending on how your code is set up, it may actually not be that difficult for you to move some of those big Folders into Racks in Specialists. Phillip mentioned the other day that this could help, and I think I spotted a BTree in the Rack code yesterday, which would explain how Racks help. I'm not sure where the rumored BTreeFolder code stands, which would be a more immediate drop in fix. It didn't look to me like Specialists were too difficult to work with, though. Kevin
Kevin Dangoor:
Here's something to think about: whenever an object is added to or removed from a folder, all objects in all neighboring folders and below are traversed. The manage_beforeDelete and manage_afterAdd hooks are called on each object.
Jason, I don't know if you've taken much of a look at ZPatterns yet...
Yes, I've been eyeing it and playing with it. It's been changing a bit, and I wanted to let Phillip and Ty settle it down before I moved my major production server to it.
Depending on how your code is set up, it may actually not be that difficult for you to move some of those big Folders into Racks in Specialists. Phillip mentioned the other day that this could help, and I think I spotted a BTree in the Rack code yesterday, which would explain how Racks help. I'm not sure where the rumored BTreeFolder code stands, which would be a more immediate drop in fix.
It didn't look to me like Specialists were too difficult to work with, though.
Kevin
That's really where I want to go. I'm sure Phillip would love to have a big fat example of ZPatterns getting hammered and working to show off too. :) All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Shane Hathaway writes: Well, I reduced the 'target size' from 20,000 object down to 1000, and the memory seems to be climbing.
Jason Spisak wrote:
After minimizing your in-memory cache, look at the manage_debug screen again. Are the refcounts still high? I bet they are...
No. The ref counts drop to hundreds.
That's a big relief. Okay, now we know that this isn't a memory leak, it's only related to the fact that your site requires ZODB to load a very large number of objects into memory in order to perform normal operations.
Here's something to think about: whenever an object is added to or removed from a folder, all objects in all neighboring folders and below are traversed. The manage_beforeDelete and manage_afterAdd hooks are called on each object.
I am hoping to use ZPatterns to stem this rapidly out of control, ObjectManger not scalable, issue.
Also, there is still the issue that Python doesn't seem to be releasing memory back to the system. I wonder whether that capability has been implemented in Python.
It would really put a damper on things if is wasn't. However, when I stopped my Zope process each time, it didn't seem to give me back what Ihad started with. Maybe there is a leak in the kernel I am using. It's 2.2.12-smp. Anyone?
Also, is see reference to 161 Products.GadflyDA.gadfly.kjparser.ParseRule, and I'm not even useing Gadfly!
What the heck is that about? Anyone?
Chances are some other product is "reaching in" to Gadfly. Do you have the Zope tutorial installed? It uses Gadfly.
No. This is a Data.fs that came from Zope 1. I didn't even think to get Gadfly out of the Products directory.
Thing's seem to be a bit nicer now that I took out an External Method that returns a DateTime object the Catalog for Indexing. However, there's only about 14,000 of objects with that property in existsnce in my DB, and they don't change often.
Here's the code:
def calendar_day(self) return int(self.calendar_date)/1000000
Used to return the unique integer day.
That code actually doesn't return a DateTime instance, just an integer.
Yeah, I didn't really think is was that. ;)
Keep me informed.
You bet. And a thousand thanks are waiting in my cache for you. Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
On Mon, 22 May 2000, Jason Spisak wrote:
Also, is see reference to 161 Products.GadflyDA.gadfly.kjparser.ParseRule, and I'm not even useing Gadfly! [...] Chances are some other product is "reaching in" to Gadfly. Do you have the Zope tutorial installed? It uses Gadfly.
No. This is a Data.fs that came from Zope 1. I didn't even think to get Gadfly out of the Products directory.
I've seen these gadfly references ever since I started looking at the manage_debug screen. My Data.fs also has no extra products installed. If something is reaching into Gadfly, it is something that ships with Zope. By the way, my site is structured into a series of folders, so that no folder has more than about 50 objects in it, with the exception (of course <grin>) of the most heavily modified folder, which has about 120 objects. But I'm still seeing this growing-memory-usage pattern. However, the memory usage does grow pretty much just when a large number of objects get updated, usually in many different folders. So if there is a Python garbage collection issue, I think that would probably explain my case, at least. It seems incredible that Python garbage collection would be broken, but I suppose Zope *is* one of the most intensive programs running in python, so if anyone is going to see it it is going to be our community. --RDM
participants (4)
-
Jason Spisak -
Kevin Dangoor -
R. David Murray -
Shane Hathaway