<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It is expected your RSS value is lower than what Erlang reports.</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">Erlang requests virtual memory from the operating system (Linux). But it is mapped into the process on-demand. RSS is the resident set size, which is the currently physical mapped pages. As Erlang hits pages it hasn't used before, a kernel trap is generated and it maps in that page to to the process.</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">For example, lets say we allocate a large array to hold processes, but we are only using a small smidgen of that array. Then there are many virtually mapped pages, but we aren't really "using" the memory yet. It is taken on-demand. This on-demand method is smart because it lowers memory pressure. Rather than having to do all the work up front, we can amortize the work over the course of the program running, which is much more efficient. If the application requests 1 gigabyte of memory say, and we want to give it right away, we must zero one gigabyte of memory. This takes time. But on-demand, we can keep a background process for zeroing memory and allocate it as it is needed, among other things.</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">Where this can create a problem is if you have several processes all wanting lots of memory, and you have less memory in the machine than what they've got promised by the kernel. Then, if they all starts wanting memory, you should expect to see various trouble.</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">As Erlang runs more, I would expect the RSS to go up as it populates more of the memory space.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 31, 2020 at 8:23 PM Vyacheslav Levytskyy <<a href="mailto:v.levytskyy@yahoo.com">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">
  
    
  
  <div>
    <p>It's linux (ubuntu). I read /proc/[pid]/statm, take RSS number of
      pages (the 2nd value in the line of that file) and calculate
      memory used by Erlang VM as RSS x page size (read as "getconf
      PAGESIZE").<br>
    </p>
    <div>On 31.01.2020 19:59, Jesper Louis
      Andersen wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">J.</div>