<div dir="ltr"><div class="gmail_extra">Could be the memory previously allocated by the BEAM is still counted as VmRss after it has freed the memory back to Linux.<br><br>Comparing /proc/meminfo before and after the internal cleanup task in your Erlang app has run might give some ideas.<br>
<br></div><div class="gmail_extra">Also, what happens with reported values after manually dropping the page cache [1]?<br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Gustav<br></div><div class="gmail_extra">
<br>[¡] <a href="http://linux-mm.org/Drop_Caches">http://linux-mm.org/Drop_Caches</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 1:40 PM, Tino Breddin <span dir="ltr"><<a href="mailto:tino.breddin@googlemail.com" target="_blank">tino.breddin@googlemail.com</a>></span> wrote:<br>
<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">Hi list,<div><br></div><div>I'm experiencing issues with a couple of Beam nodes where I see a huge gap between the node's reported memory usage and the underlying Linux Kernel's view.</div>
<div><br>

</div><div>This is using R15B01.</div><div><br></div><div>As a start an application in such a node stores a lot of tuples (containing atoms and binary data) in ETS tables. That proceeds until a point where memory usage is 70% (6GB) of the available memory. At that point erlang:memory() and top (or /proc/PID/status) agree roughly on the memory usage. Then an internal cleanup task is performed, which clears obsolete records from the ETS tables. Afterwards, erlang:memory() reports an expected low value of roughly 60MB memory usage. (This includes binary data). However, the kernel still reports the high memory usage values (both VmRss and VmTotal) for the node. The kernel's usage view will stay stable until the ETS tables are filled to a point where the real memory usage exceeds the kernel's view, then the kernel reported usage will grow as well.</div>


<div><br></div><div>Now having checked the node in some details I'm wondering what causes this difference between the BEAM's view and the Kernel's view on memory usage. I have 2 ideas which I'm checking right now.</div>


<div><br></div><div>(1) Not GC'ed binaries: Could it be that binary data is not GC'ed because the original dispatcher process which it was passed through before being stored in an ETS table is still alive. Thus there is still some reference to it? However, this would not explain why erlang:memory() reports a very low value for used memory for binaries.</div>


<div><br></div><div>(2) low-level memory leak: Some driver or NIF leaking memory, which would obviously not be reported by erlang:memory(). However, then it surprises me that the Kernel's view stays stable while the BEAM's actual memory usage is still below the Kernel's view. It should be continuously growing in this case imho.</div>


<div><br></div><div>I'd appreciate if anyone has some more insight or experience with such a behaviour, while I'm further digging into this.</div><div><br></div><div>Cheers,</div><div>Tino</div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div>