<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>That's awesome. Looking forward to seeing it.<br><br><hr>Date: Sat, 24 Dec 2011 11:40:50 +0100<br>From: kenneth.lundin@gmail.com<br>To: zabrane3@gmail.com<br>CC: erlang-questions@erlang.org<br>Subject: Re: [erlang-questions] Fail fast<br><br>We have been discussing things like this for several years now. But like a coincidence we have in our plans that something should happen in this area during the year.<br>
Cannot be more specific, yet.<BR>
Kenneth Erlang/OTP Ericsson<BR>
<div class="ecxgmail_quote">Den 23 dec 2011 22:14 skrev "Zabrane Mickael" <<a href="mailto:zabrane3@gmail.com">zabrane3@gmail.com</a>>:<br><blockquote class="ecxgmail_quote" style="border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Fantastic Tony.<div><br></div><div>Any chance to see these features officially integrated one day ... OTP folks?</div><div><br></div><div><div>Regards,</div><div>Zabrane</div><div><br></div>
<div><div>On Dec 23, 2011, at 6:32 PM, Tony Rogvall wrote:</div><br><blockquote><div style="word-wrap:break-word">Hi!<div><br></div><div>If you are really, really interested in these kind of thing then maybe you could have a look in </div>
<div><a href="http://github.com/tonyrog/otp" target="_blank">github.com/tonyrog/otp</a> in the branch limits.</div><div><br></div><div>It basically implements som new options to spawn_opt to set up resource limits like:</div>
<div><br></div><div>max_memory</div><div>max_time</div><div>max_cpu</div><div>max_reductions</div><div>max_processes</div><div>max_ports</div><div>max_tables</div><div>max_message_queue_len</div><div><br></div><div>limits are inherited by spawned process and some of the resources are </div>
<div>shared among the spawn processes to form a kind of resource group.</div><div><br></div><div>The implementation is experimental and was made in order to demonstrate the </div><div>features for the OTP group. Time for an EEP?</div>
<div><br></div><div>Flavors of max_message_queue_len could be let sender crash, receiver crash, sender block</div><div>(not so erlangish: drop head of message queue , drop tail of message queue )</div><div><br></div><div>
<br></div><div>/Tony</div><div><br></div><div><br><div><div>On 23 dec 2011, at 18:04, Chandru wrote:</div><br><blockquote>Yes, I agree. I asked for "bounded message queues" a long time ago, but I got voted down :(<br>
<br><a href="http://erlang.org/pipermail/erlang-questions/2008-June/035517.html" target="_blank">http://erlang.org/pipermail/erlang-questions/2008-June/035517.html</a><br>
<br>Chandru<br><br><div class="ecxgmail_quote">On 23 December 2011 14:44, Matthew Evans <span dir=ltr><<a href="mailto:mattevans123@hotmail.com">mattevans123@hotmail.com</a>></span> wrote:<br><blockquote class="ecxgmail_quote" style="border-left:1px #ccc solid;padding-left:1ex">
<div><div dir=ltr>Email got sent too soon.....<BR><div><br><BR>The ability to handle this is a "feature" that I think is missing from Erlang. The VM and the language is very stable, but the fact that a single, poorly behaving, process can cause the VM to die is pretty undesirable. I had a bug in a "logging" process where an ETS table wasn't getting purged properly. It grew and grew eventually bringing down the entire VM due to an OOM condition. This process wasn't significant to the operation of the system, (and if I wanted it to be I would've written a supervisor to manage it), yet it killed a critical service.<BR>
<br><BR>
</div>My personal wish would be the ability to optionally apply limits to a process when it is spawned (memory, ets table sizes, message queue would be a good start). When one or more of the limits are exceeded the process can be killed (and then trapped/supervised if needed). It would make the VM more stable, and would also assist in debugging (since it would be easy to see in the sasl logs what happened without needing to look at a crash dump). One other advantage of this is the ability to assist in testing, having the limits set temporarily to find possible memory hogs and issues with head of line blocking (message queues growing too much). Those limits would be removed for production.<BR>
<br><BR>An option like that would, IMO, be a useful addition to the language.<BR><br><BR>Cheers<BR><br><BR>Matt<BR><br><div><div><div></div><hr>From: <a href="mailto:chandrashekhar.mullaparthi@gmail.com">chandrashekhar.mullaparthi@gmail.com</a><br>
Date: Fri, 23 Dec 2011 07:44:49 +0000<br>To: <a href="mailto:jwatte@gmail.com">jwatte@gmail.com</a><br>CC: <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>Subject: Re: [erlang-questions] Fail fast<br>
<br></div><div><div>No, if BEAM cannot allocate more memory, the node just dies. In case you are interested, this handling of OOM condition has been discussed on the mailing list in the past. Supervision hierarchies don't help in this case.<br>
<br>cheers<br>Chandru<br><br><div>On 23 December 2011 02:03, Jon Watte <span dir=ltr><<a href="mailto:jwatte@gmail.com">jwatte@gmail.com</a>></span> wrote:<br><blockquote style="border-left:1px #ccc solid;padding-left:1ex">
If there was a proper supervision hierarchy all the way up to the "root" of the application, why would this happen? Wouldn't the supervisors just kill off whatever process ends up not being able to allocate memory, and thus clean up? (Perhaps kicking off users at the same time) If it fails far enough up, wouldn't it basically reset the erl environment to "scratch" ? Or would that be expecting too much from the supervision hierarchy?<div>
<br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><span><font color="#888888"><br clear=all><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br></font></span><div><div><div>On Tue, Dec 20, 2011 at 6:23 PM, Chandru <span dir=ltr><<a href="mailto:chandrashekhar.mullaparthi@gmail.com">chandrashekhar.mullaparthi@gmail.com</a>></span> wrote:<br>
</div></div><blockquote style="border-left:1px #ccc solid;padding-left:1ex"><div><div>
Hello everyone,<br><br>I've just had a failure in one of my live services because an erlang node ran out of memory (caused by a traffic spike). Restart mechanisms exist to restart the node, but the node took a long time to die because it was writing a large erl_crash.dump file, and then there was a 7GB core dump.<br>
<br>Is there a quicker way to fail? I'm thinking of disabling core dumps entirely on the box. What else can I do? A configuration option on the node to only produce a summary erl_crash.dump would be nice. The most useful things for me in a crash dump usually are the slogan at the top, and the message queue lengths of each process. In this particular case, the slogan would've told me all that I needed to know.<span><font color="#888888"><br>
<br>Chandru<br><br>
</font></span><br></div></div><div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br>
<br>_______________________________________________
erlang-questions mailing list
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></div></div></div> </div></div>
</blockquote></div><br>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br><div>
<div><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;font-size:12px">"Installing applications can lead to corruption over time. </span><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;font-size:12px">Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"</span></div>
<div><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;font-size:12px"><br></span></div><br>
</div>
<br></div></div>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><div><br>
</div>
<br></div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div>
<br>_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions </div></body>
</html>