
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 28 Jul 2011, at 04:23, Jon Watte wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>A rack in each city? Is the Erlang kernel getting more latency tolerant?</div></blockquote><div><br></div><div>I assume you are referring to the occasional "node not responding" issues? As far as I know, the kernel doesn't have issues with latency.</div><div><br></div><div>The problems with Distributed Erlang are related to a heavy-handed backpressure solution, where processes trying to send to the dist_port are simply suspended if the output queue exceeds a given threshold. When the queue falls under the threshold, all suspended processes are resumed. Since the algorithm doesn't differentiate between processes, this fate can befall the net ticker as well.</div><div><br></div><div>This *has* been improved a bit in the latest release, and I believe more improvements are forthcoming. Simply increasing the thresholds (currently not configurable) should mostly eliminate the problem.</div><div><br></div><blockquote type="cite"><div>So, the *current* best-value hardware looks something like:</div><div>32 GB of RAM</div><div>24 hardware threads (in 2-way NUMA, btw -- does BEAM pay attention to memory affinity?)</div><div>240 GB SSD, 1 or 2 (RAID-1 for redundancy)</div>

<div>Probably 10 Gbps networking</div></blockquote><div><br></div><div>BEAM is starting to make use of NUMA, for example when allowing you to control the binding of schedulers to cores. See e.g. </div><div><br></div><div><a href="http://www.erlang.org/doc/man/erl.html">http://www.erlang.org/doc/man/erl.html</a> (search for NUMA)</div><div><br></div><div>I believe that the current activities are mainly laying the groundwork for some more powerful optimizations, e.g. delayed deallocation, but R14B actually included quite a few improvements already, esp. in regard to locking.</div><div><br></div><div><a href="http://www.erlang.org/download/otp_src_R14B.readme">http://www.erlang.org/download/otp_src_R14B.readme</a></div><div><br></div><div>Still, micro benchmarks have indicated that memory allocation (not least GC meta-data) locking issues mainly start affecting performance somewhere beyond 40 cores. The question is how much this really affects applications on the "usual" hardware of today?</div><div><br></div><div>One problem is that it's hard to do detailed profiling on complex real-world applications. The issues limiting scalability might well be wholly unrelated to core VM aspects such as GC, scheduling and message passing. In the first SMP experiments with Ericsson's Telephony Gateway Controller, the big bottleneck was the big lock protecting the ports and linked-in drivers.</div><div><br></div><br><blockquote type="cite"><div>Next year's best-value hardware will probably look something like:</div><div>64 GB of RAM</div><div>40 hardware threads (still with 2-way NUMA)</div><div>240 GB SSD, 1 or 2 (RAID-1 for redundancy) (it will be cheaper than this year, but still the "sweet spot" unless you're building RAID 6 volumes or something)</div>

<div>Definitely 10 Gbps networking</div></blockquote><br></div><div><br></div><div>Yes, but one thing I learned while at Ericsson was that NEBS-compliant ATCA processor boards don't exactly stay on the leading edge of processor capacity. The top-end blade servers today seem to host up to two dual- or quad-core processors. This is not to say that everyone has to evolve at the same pace, but the main funding sources for Erlang/OTP tend to follow this path.</div><div><br></div><div>Now, Joe has publicly mentioned running an application on a 24-core architecture, for which the optimum setup at the time seemed to be 4 erlang nodes - one for each physical CPU. The problems arise when the application isn't embarrassingly parallel, but requires processes to actually interact with each other, sometimes in fairly complex ways. Also, these many-core architectures are still finding their way in terms of memory access architectures, and each vendor has different ideas. The combination of bottlenecks in the VM, limitations of the hardware architecture, and complex interaction patterns, can easily result in emergent behaviour, which can be quite dramatic.</div><div><br></div><div>My own take on this is that it's something we will have to learn to live with, and I started developing Jobs - a load control framework (<a href="http://github.com/esl/jobs">http://github.com/esl/jobs</a>) to allow for "traffic regulation" of erlang-based systems similarly to how one achieves quality of service on TCP-based networks (another messaging system).</div><div><br></div><div>The key, in my experience, is not usually to go as fast as possible, but to deliver reliable and predictable performance that is good enough for the problem at hand. As many have pointed out through the years, Erlang was never about delivering maximum performance.</div><div><br></div><div>BR,</div><div>Ulf W</div><div><br></div><div>

<div>Ulf Wiger, CTO, Erlang Solutions, Ltd.</div><div><a href="http://erlang-solutions.com">http://erlang-solutions.com</a></div><div><br></div><br class="Apple-interchange-newline">

</div>

<br></body></html>