<div dir="ltr">Hi,<div><br></div><div>I don't think the runtime (BEAM) is at fault here since the stable memory usage reported by the kernel can go on for a week, depending how fast the real memory usage catches up.</div>
<div><br></div><div>Tino</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 1:51 PM, Masklinn <span dir="ltr"><<a href="mailto:masklinn@masklinn.net" target="_blank">masklinn@masklinn.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013-09-16, at 13:40 , Tino Breddin wrote:<br>
><br>
> (1) Not GC'ed binaries: Could it be that binary data is not GC'ed because<br>
> the original dispatcher process which it was passed through before being<br>
> stored in an ETS table is still alive. Thus there is still some reference<br>
> to it? However, this would not explain why erlang:memory() reports a very<br>
> low value for used memory for binaries.<br>
><br>
> (2) low-level memory leak: Some driver or NIF leaking memory, which would<br>
> obviously not be reported by erlang:memory(). However, then it surprises me<br>
> that the Kernel's view stays stable while the BEAM's actual memory usage is<br>
> still below the Kernel's view. It should be continuously growing in this<br>
> case imho.<br>
><br>
> I'd appreciate if anyone has some more insight or experience with such a<br>
> behaviour, while I'm further digging into this.<br>
<br>
</div>I have no info, but I'd suggest #3: the runtime does not release memory<br>
back to the OS under the assumption that the high-water mark probably<br>
isn't a unique event; or there is some delay between the moment where<br>
memory is released to the runtime and where memory is released by the<br>
runtime to the kernel (IIRC CPython has such a behavior with multi-stage<br>
allocations, internal pools and freelists[-1] and that's a fairly recent<br>
evolution, before 2006 CPython *never* released memory to the kernel[0]).<br>
<br>
[-1] this means memory released by a Python program may or may not be<br>
     immediately free()'d back to the kernel, and due to release being<br>
     predicated upon arena emptying[0] and ignoring freelists it will<br>
     not happen for all internally released memory, at least not without<br>
     an explicit full GC and maybe even with that<br>
[0] <a href="http://bugs.python.org/issue1123430" target="_blank">http://bugs.python.org/issue1123430</a><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>
</blockquote></div><br></div>