<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 10:22 AM, Lukas Larsson <span dir="ltr"><<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For the record, CPU utilization is a terrible way to measure load on a system, especially if you are running on much less than full throttle. Because of how expensive it is to go to sleep, all the threads in the Erlang VM will spin and consume CPU when it is out of work and if you are running at 25% CPU then you are running out of work very often which will cause more spinning which will increase CPU while not decreasing the amount of work the system can do.</blockquote></div><br></div><div class="gmail_extra">This was exactly the same idea I had when I read that. Apart from what Lukas is mentioning, you may be able to avoid some TLB shootdowns by locking CPU cores to schedulers via +sbt db. For these kinds of situations, this can improve the CPU % usage as well since one core waiting for the L1,L2,L3 cache to populate counts as active CPU time. And if other cores are able to kill the TLB, you will have lots of traps to the OS and lots of higher CPU times.<br><br></div><div class="gmail_extra">Another venture you may want to try is to tune the memory allocator a bit. If all the messages you receive have the same rough structure, you can win a lot by making it easier for the system to grab memory of that size. This is quite machine-specific however and usually don't win you much unless you are up against a wall--but that seems to be the case here.<br><br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>