<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><title>Re: [Openstack] Memory leaks from greenthreads</title><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>> Has there been any thinking around only using eventlet/greenlet for webserver endpoints and using something like multiprocessing for everything else?<br><br></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I was already beginning to think that this would be a good blueprint/discussion topic for the design summit ;-)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>We’ve seen a number of issues with the eventlet approach in the computer & network manager where a long running activity (such as updating all security groups, creating and uploading a snapshot) will block any other activities. Whilst it’s possible to work round the first of these types of issues by planting sleep(0) statements in the loop, snapshot upload is still a problem.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Of course making everything thread safe isn’t going to be trivial, although there is lock code in place for things like iptables I suspect that there are a whole bunch of other timing / concurrency issues that we’ll find once we move to a full threaded model. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Phil<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> openstack-bounces+philip.day=hp.com@lists.launchpad.net [mailto:openstack-bounces+philip.day=hp.com@lists.launchpad.net] <b>On Behalf Of </b>Joshua Harlow<br><b>Sent:</b> 29 February 2012 21:26<br><b>To:</b> Vishvananda Ishaya; openstack<br><b>Subject:</b> Re: [Openstack] Memory leaks from greenthreads<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Cool.<br><br>Just a thought I was having, that others might want to chime in on.<br><br>Has there been any thinking around only using eventlet/greenlet for webserver endpoints and using something like multiprocessing for everything else?<br><br>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 <i>monkey patch</i>. Maybe the python people plan for multiprocess to replace eventlet/greenlet in the end anyway???<br><br>Thoughts?<br><br>On 2/29/12 12:48 PM, "Vishvananda Ishaya" <<a href="vishvananda@gmail.com">vishvananda@gmail.com</a>> wrote:</span><o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Hello Everyone,<br><br>We have had a memory leak due to an interaction with eventlet for a while that Johannes has just made a fix for.<br><br>bug:<br><a href="https://bugs.launchpad.net/nova/+bug/903199">https://bugs.launchpad.net/nova/+bug/903199</a><br><br>fix:<br><a href="https://bitbucket.org/which_linden/eventlet/pull-request/10/monkey-patch-threadingcurrent_thread-as">https://bitbucket.org/which_linden/eventlet/pull-request/10/monkey-patch-threadingcurrent_thread-as</a><br><br>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.<br><br>Vish</span><o:p></o:p></p></div></body></html>