A thought for 2.6 about various leaks and memory problems
For the last few weeks (And maybe longer) I have been seeing lots of messages about zope leaking, the gc crashing and generally, Zope going senile after long runtimes or lots of requests. This was (And I believe still is) a problem for Apache, which they solved by having threads only live for a certain number of calls, then they die and are replaced by newly created threads. I know that with the current ZODB access model, this would be too slow, but is there any way that the opening of the ZODB could be moved to a different thread or earlier, before the fork, so that we could simply kill senile threads without killing the entire shooting match? I'll admit that I don't know enough about the core code to impliment this (And it is not solving the problem, only masking it) but it might be a good way for "the rest of us" to get back working on reliable Zope's while the core guys get the leaks located and plugged. Just a thought Adrian... -- The difficulty of tactical maneuvering consists in turning the devious into the direct, and misfortune into gain. - Sun Tzu
On Tue, 19 Mar 2002 08:08:47 -0000, "Adrian Hungate" <adrian@haqa.co.uk> wrote:
For the last few weeks (And maybe longer) I have been seeing lots of messages about zope leaking, the gc crashing and generally, Zope going senile after long runtimes or lots of requests. This was (And I believe still is) a problem for Apache, which they solved by having threads only live for a certain number of calls, then they die and are replaced by newly created threads. I know that with the current ZODB access model, this would be too slow, but is there any way that the opening of the ZODB could be moved to a different thread or earlier, before the fork, so that we could simply kill senile threads without killing the entire shooting match?
Sure. Run two Zope processes connected to a single ZEO server. If you use a load balancer that knows to avoid a dead backend, then you are safe as long as the zopes dont go down at the same time. See also this proposal for getting lame Zopes killed quickly: http://dev.zope.org/Wikis/DevSite/Proposals/ToleratingHangsAndLeaks Toby Dickenson tdickenson@geminidataloggers.com
AutoLance is an implementation of the proposal, too: http://www.zope.org/Members/mcdonc/Products/AutoLance ----- Original Message ----- From: "Toby Dickenson" <tdickenson@devmail.geminidataloggers.co.uk> To: "Adrian Hungate" <adrian@haqa.co.uk> Cc: <zope-dev@zope.org> Sent: Tuesday, March 19, 2002 8:31 AM Subject: Re: [Zope-dev] A thought for 2.6 about various leaks and memory problems On Tue, 19 Mar 2002 08:08:47 -0000, "Adrian Hungate" <adrian@haqa.co.uk> wrote:
For the last few weeks (And maybe longer) I have been seeing lots of messages about zope leaking, the gc crashing and generally, Zope going senile after long runtimes or lots of requests. This was (And I believe still is) a problem for Apache, which they solved by having threads only live for a certain number of calls, then they die and are replaced by newly created threads. I know that with the current ZODB access model, this would be too slow, but is there any way that the opening of the ZODB could be moved to a different thread or earlier, before the fork, so that we could simply kill senile threads without killing the entire shooting match?
Sure. Run two Zope processes connected to a single ZEO server. If you use a load balancer that knows to avoid a dead backend, then you are safe as long as the zopes dont go down at the same time. See also this proposal for getting lame Zopes killed quickly: http://dev.zope.org/Wikis/DevSite/Proposals/ToleratingHangsAndLeaks Toby Dickenson tdickenson@geminidataloggers.com _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
participants (3)
-
Adrian Hungate -
Chris McDonough -
Toby Dickenson