<p>In my experience, using excessive timers once bit me hard due to lock contention on global timers lock in Erts. Roughly it was about 3-5 timers created/expired for each of around 200k-500k processes at roughly the same moment (a big broadcast to all processes). Fortunately lcnt showed the problem which was slowing down the broadcast tenfold - lock conflicts was at 95% level on timers lock.</p>

<div class="gmail_quote">On Sep 22, 2012 8:07 AM, "Rapsey" <<a href="mailto:rapsey@gmail.com">rapsey@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>3. Is spawning a lot of send_after's or timers a dangerous idea? In case of using timer module, we'll just lose some started timers due to port restart. But something tells me that crash of erlang internal timers is a somewhat more dangerous thing that might even crash the VM.</div>


<div><br></div></blockquote><div>How much is a lot of send_afters? My server runs a lot of timers, but very rarely in more than one per process. But there can easily be thousands of timers running in different processes.</div>

I would advise against using timer module. Using the timer module in a few places turned out to be a big mistake. It sometimes just stops working completely. It may be a mistake on my part, but erlang:send_after generally does everything you need and is completely reliable.<div>

<br></div><div><br></div><div>Sergej </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>