openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #08124
Re: Memory leaks from greenthreads
Cool.
Just a thought I was having, that others might want to chime in on.
Has there been any thinking around only using eventlet/greenlet for webserver endpoints and using something like multiprocessing for everything else?
I know its a fundamental change, but it would force people to think about how to break up there code into something that would work with a message passing architecture (this is already happening with nova + rabbitmq). Nova is a good example, but my thought was to go even further and have anything that needs to run for a long time (ie a equivalent of a nova manager) that is shared inside a application also be a separate "process" with a queue for message passing. Then maybe eventlet/greenlet isn't needed at all? This would force good interfaces, and we wouldn't have to worry about missing a monkey patch. Maybe the python people plan for multiprocess to replace eventlet/greenlet in the end anyway???
Thoughts?
On 2/29/12 12:48 PM, "Vishvananda Ishaya" <vishvananda@xxxxxxxxx> wrote:
Hello Everyone,
We have had a memory leak due to an interaction with eventlet for a while that Johannes has just made a fix for.
bug:
https://bugs.launchpad.net/nova/+bug/903199
fix:
https://bitbucket.org/which_linden/eventlet/pull-request/10/monkey-patch-threadingcurrent_thread-as
Unfortuantely, I don' t think we have a decent workaround for nova while that patch is upstreamed. I wanted to make sure that all of the distros are aware of it in case they want to carry an eventlet patch to prevent the slow memory leak.
Vish
Follow ups
References