<div dir="ltr">Hi,<div><br></div><div>Under highish loads (upwards of 2,000 messages/s), RabbitMQ requires more than one of our CPU cores, which is fine. However, after a long (undetermined) period of uptime of the Erlang VM these scheduler threads seem to become unused. Looking in top/htop with thread views enabled, only one thread (always the same thread) is used and is constantly pegged at 99% of a core. The other threads barely reach 0.1%. We run the Erlang VM with default flags, e.g. no +S or +s options. Some information about the schedulers and CPU bindings etc:</div><div><br></div><div><div># rabbitmqctl eval 'erlang:system_info(schedulers_online).'</div><div>24</div><div># rabbitmqctl eval 'erlang:system_info(schedulers).'</div><div>24</div><div># rabbitmqctl eval 'erlang:system_info(cpu_topology).'</div><div>[{node,[{processor,[{core,[{thread,{logical,1}},{thread,{logical,13}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,3}},{thread,{logical,15}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,5}},{thread,{logical,17}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,7}},{thread,{logical,19}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,9}},{thread,{logical,21}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,11}},{thread,{logical,23}}]}]}]},</div><div>&nbsp;{node,[{processor,[{core,[{thread,{logical,0}},{thread,{logical,12}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,2}},{thread,{logical,14}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,4}},{thread,{logical,16}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,6}},{thread,{logical,18}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,8}},{thread,{logical,20}}]},</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {core,[{thread,{logical,10}},{thread,{logical,22}}]}]}]}]</div><div># rabbitmqctl eval 'erlang:system_info(logical_processors_online).'</div><div>24</div><div># rabbitmqctl eval 'erlang:system_info(multi_scheduling).'</div><div>enabled</div><div># rabbitmqctl eval 'erlang:system_info(schedulers).'</div><div>24</div><div># rabbitmqctl eval 'erlang:system_info(scheduler_bindings).'</div><div>{unbound,unbound,unbound,unbound,unbound,unbound,unbound,unbound,unbound,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;unbound,unbound,unbound,unbound,unbound,unbound,unbound,unbound,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;unbound,unbound,unbound,unbound,unbound,unbound,unbound}</div><div># rabbitmqctl eval 'erlang:system_info(threads).'</div><div>true</div><div># rabbitmqctl eval 'erlang:system_info(thread_pool_size).'</div><div>30</div></div><div><br></div><div>beam command line:</div><div><br></div><div>/usr/lib64/erlang/erts-5.10.1/bin/beam.smp -W w -K true -A30 -P 1048576 -- -root /usr/lib64/erlang -progname erl -- -home /var/lib/rabbitmq -- -pa /usr/lib/rabbitmq/lib/rabbitmq_server-3.1.0/sbin/../ebin -noshell -noinput -s rabbit boot -sname rabbit@rabbit-node-name -boot start_sasl -config /etc/rabbitmq/rabbitmq -kernel inet_default_connect_options [{nodelay,true}] -sasl errlog_type error -sasl sasl_error_logger false -rabbit error_logger {file,"/var/log/rabbitmq/rabbit@rabbit-node-name.log"} -rabbit sasl_error_logger {file,"/var/log/rabbitmq/rabbit@rabbit-node-name-sasl.log"} -rabbit enabled_plugins_file "/etc/rabbitmq/enabled_plugins" -rabbit plugins_dir "/usr/lib/rabbitmq/lib/rabbitmq_server-3.1.0/sbin/../plugins" -rabbit plugins_expand_dir "/var/lib/rabbitmq/mnesia/rabbit@rabbit-node-name-plugins-expand" -os_mon start_cpu_sup false -os_mon start_disksup false -os_mon start_memsup false -mnesia dir "/var/lib/rabbitmq/mnesia/rabbit@rabbit-node-name"<br></div><div><br></div><div>htop screenshot (at not-quite-full load):&nbsp;http://i.imgur.com/fom6Cwa.png</div><div><br></div><div>After this point of only one core being utilised and high loads being encountered, message throughput hits a ceiling, the run_queue grows and the Management API becomes unresponsive (we use it for a lot of monitoring).</div><div><br></div><div>To rectify the situation, we attempted first to do a rabbitmqctl stop_app, rabbitmqctl start_app (our nodes are clustered with mirrored queues) but this didn't help. In the end we shut down the app and restarted the Erlang VM as a whole. Suddenly we see 6-8 threads all using about 70% CPU, throughput increases to where it should be, run_queue is always 0 and the Management API is fully responsive.</div><div><br></div><div>We currently have 4 nodes in this "stuck" situation on our less-critical workloads, so we are able to provide any debugging information required.</div><div><br></div><div>We're running 24 "cores" worth of Xeon E5645 on RHEL5.6&nbsp;2.6.18-238.27.1.el5. We're running RabbitMQ both 3.1.0 and 3.1.5 on a self-compiled RPM of Erlang OTP R16B with HiPE disabled.</div><div><br></div><div>Thanks in advance for any help, and let me know if we can provide any further information, straces, netstats etc.</div><div><br></div><div>Paul Bowsher</div><div>Senior Engineer</div><div>Global Personals</div></div>