<div dir="ltr"><div>I remember that battle with Erlang vs OS memory reporting well, it was such a show. This captures my thinking from 2017: <a href="https://github.com/rabbitmq/rabbitmq-server/issues/1223">https://github.com/rabbitmq/rabbitmq-server/issues/1223</a> . This has more context: <a href="https://github.com/rabbitmq/rabbitmq-server/pull/1259#issuecomment-308428057">https://github.com/rabbitmq/rabbitmq-server/pull/1259#issuecomment-308428057</a>. There are a few other comments in that thread that you may find useful.</div><div><br></div><div>Erlang will either over-report or under-report the memory used. erlang:memory(total) will very rarely match the physical RSS mapping, as explained earlier by Jesper + <a href="https://stackoverflow.com/questions/7880784/what-is-rss-and-vsz-in-linux-memory-management">https://stackoverflow.com/questions/7880784/what-is-rss-and-vsz-in-linux-memory-management</a>. This detailed snapshot of Erlang memory allocators state shows this in the clearest way that I am aware of: <a href="https://grafana.gcp.rabbitmq.com/dashboard/snapshot/wM5JcgR9oQToU4CR54IbOq1NtAsa6jvu">https://grafana.gcp.rabbitmq.com/dashboard/snapshot/wM5JcgR9oQToU4CR54IbOq1NtAsa6jvu</a> </div><div><br></div><div>As it stands, the Linux OOM takes action based on the RSS value. While from an Erlang perspective it may seem OK to ask the OS for more memory, we've had years of poor RabbitMQ experience when the Erlang VM process would get killed by the Linux OOM because it was asking for memory that the system didn't have available. This has more information: <a href="https://www.rabbitmq.com/memory-use.html">https://www.rabbitmq.com/memory-use.html</a></div><div><br></div><div>Hope this helps, Gerhard.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 31, 2020 at 7:00 PM Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">When you say /proc/pid, what are you looking at specifically in there? It is a bit different depending on which Unix you run on, so a simple example will help a lot.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In particular, my early guess is going to be virtual memory vs physical RSS mapping. The former can be much higher than the latter. Especially in system such as Linux, which allow overcommitting memory.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 31, 2020 at 7:22 PM Vyacheslav Levytskyy <<a href="mailto:v.levytskyy@yahoo.com" target="_blank">v.levytskyy@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I wonder why memory used by Erlang VM as reported by the kernel via the <br>
/proc/pid differs from erlang:memory(total). In my current configuration <br>
I observe realistic response from erlang:memory(total) and much lower <br>
values from the /proc/pid.<br>
<br>
I'm not surprised by the difference itself, but rather by the fact that <br>
the /proc/pid gives unrealistically lower values -- I'm not 100% sure, <br>
but it looks like RabbitMQ is using the /proc/pid approach by default, <br>
proposing also recon_alloc:memory(allocated) and erlang:memory(total) as <br>
available options of Erlang VM memory consumption calculation strategy.<br>
<br>
Does anybody have insights of what and why is going on with those <br>
calculations of memory used by Erlang VM? Is it possible to select one <br>
strategy beforehand for my Erlang app, or I must measure on each new <br>
configuration what looks more precise? Should I compare and change the <br>
strategy during run-time, or after I selected a strategy once for my <br>
configuration I can be sure that selected approach always better than <br>
other two?<br>
<br>
Thank you,<br>
Vyacheslav<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">J.</div>
</blockquote></div>