<div dir="ltr"><div>We are running on Erlang 20.3.4 on <font face="monospace, monospace" style="background-color:rgb(238,238,238)">Linux 4.4.0-119-generic 14.04.1-Ubuntu SMP x86_64</font>. These are the flags that we use for beam.smp:</div><div><br></div><div><font face="monospace, monospace" style="background-color:rgb(238,238,238)">/var/vcap/packages/erlang-20.3.4/lib/erlang/erts-9.3/bin/beam.smp -W w -A 64 -zdbbl 128000 -K true -stbt db -zdbbl 128000 -P 1048576 -t 5000000 -MHas ageffcbf -MBas ageffcbf -MHlmbcs 512 -MBlmbcs 512</font></div><div><br></div><div>When the node boots, the binary_alloc multiblock carrier utilization is ~99% (90MB allocated, 90MB used). [1]</div><div><br></div><div>As the load on the node starts, binary_alloc mbcs util drops to ~78% (~800MB allocated, ~625MB used). [2]</div><div><br></div><div>When load stops completely, binary_alloc mbcs util drops to ~61%  (~55MB allocated, ~35MB used) & mbcs_pool goes to ~36% (~215MB allocated, ~80MB used). In the context of RabbitMQ, this is a big problem since memory usage controls whether incoming messages are blocked or not (a.k.a. memory alarm). It's essential that the Erlang VM utilises memory as efficiently as possible, otherwise nodes under no load can remain blocked permanently. [3]</div><div><br></div><div>Our goal is for the Erlang VM to have as little unused memory as possible. As you could see in the referenced screenshots [1][2][3], the total unused memory starts at ~30MB and grows to ~280MB. Considering that the total RSS memory that the beam.smp process uses is 545MB [3], half of it goes unused (~280MB), and this is a big problem for RabbitMQ, as mentioned above.</div><div><br></div><div>Lukas, you've shared some excellent documentation in the past around the topic of memory management in Erlang. I am wondering if you have deeper/more refined insights that could help our current challenge. In Erlang Memory Management Battle Stories [5], on slide 29, you mention "Decreasing largest mbc size will make more carriers and hopefully be able to free them". In our case, it doesn't, and I'm hoping that you can point us in the right direction.</div><div><br></div><div>Ferd, I've studied your past battles with Erlang's memory management, and I can only thank you for sharing so much over the years. Erlang in Anger [6] and recon [7] helped immensely, thank you. I would appreciate greatly if you could nudge us in the right direction, maybe we've missed something.</div><div><br></div><div>During this exploration, there's a specific thing that's been bugging us: why is RSS smaller than the allocated memory? </div><div><br></div><div>Thank you all, Gerhard & Loïc.</div><div><br></div><div>[1]: <a href="https://s3-eu-west-1.amazonaws.com/rabbitmq-share/memory-allocators/mbcs_utilization_after_boot.png">https://s3-eu-west-1.amazonaws.com/rabbitmq-share/memory-allocators/mbcs_utilization_after_boot.png</a></div><div>[2]: <a href="https://s3-eu-west-1.amazonaws.com/rabbitmq-share/memory-allocators/mbcs_utilisation_under_load.png">https://s3-eu-west-1.amazonaws.com/rabbitmq-share/memory-allocators/mbcs_utilisation_under_load.png</a></div><div>[3]: <a href="https://s3-eu-west-1.amazonaws.com/rabbitmq-share/memory-allocators/mbcs_utilisation_after_load.png">https://s3-eu-west-1.amazonaws.com/rabbitmq-share/memory-allocators/mbcs_utilisation_after_load.png</a></div><div>[4]: <a href="http://erlang.org/doc/man/erts_alloc.html">http://erlang.org/doc/man/erts_alloc.html</a></div><div>[5]: <a href="http://www.erlang-factory.com/static/upload/media/139454517145429lukaslarsson.pdf">http://www.erlang-factory.com/static/upload/media/139454517145429lukaslarsson.pdf</a></div><div>[6]: <a href="https://www.erlang-in-anger.com/">https://www.erlang-in-anger.com/</a></div><div>[7]: <a href="https://github.com/ferd/recon">https://github.com/ferd/recon</a></div></div>