<div dir="ltr"><div class="gmail_quote"><div dir="ltr">With regards to RabbitMQ performance and my previous post, I found some C code from Linux Journal that sets the processor affinity mask for an already running Linux OS process from the command line. I modified the code a bit to work with the most recent Linux APIs and to have a slightly more intuitive user interface. <br>
<br>Link to unmodified code: <a href="http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/067/6799/6799l1.html" target="_blank">http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/067/6799/6799l1.html</a><br>
<br>Example:<br><br><span style="font-family: courier new,monospace;">efine@ender:~/linux$ ./bindcpu 6609 1000</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">New mask to be applied: 1000</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">pid 6609's old affinity: 1111</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">pid 6609's new affinity: 1000</span><br>
<br>In the above example, I modified the affinity of an Erlang process that was started with +S 1. The old affinity allowed it to run on any of the 4 CPUs on my system. The new one allows it to run only on CPU 3. The mask is a bit string that lets you specify the affinity for up to 1024 processors by specifying a '1' in the corresponding bit position. Bit 0 is the rightmost position in the string. I verified using 'top' that I could change the CPU on which the beam VM ran, even while it was executing code.<br>
<br>On an 8-core system, one could conceivably leave processor 0 for the OS, and perhaps reserve processors 1 through 4 for clustered RabbitMQ Erlang VMs and the rest for other apps. One additional trick that one can use (disclaimer: VERY carefully! I haven't tried it with Erlang and one could really mess up one's system) is to raise the priority of the Erlang VM Linux (OS) processes so that they preempt less important processes and therefore effectively "reserve" the affinitied CPUs for themselves. I've seen this approach used in a major US telecomms IT department to maximize database performance, but the database processes were designed to be used like that, hence my caution.<br>
<br>Anyone interested in seeing if there are RabbitMQ performance improvements by doing this? I'd be happy to post the code (which is very short, 125 lines of C). Otherwise I will play around with it on non-RabbitMQ code as time permits.<br>
<br>Regards,<br>Edwin Fine<br><br></div>
</div>
</div>