<div dir="ltr"><div style="font-size:12.8px"><span style="font-size:small">On Sat, Sep 19, 2015 at 2:34 PM, Siraaj Khandkar </span><span dir="ltr" style="font-size:small"><<a href="mailto:siraaj@khandkar.net" target="_blank">siraaj@khandkar.net</a>></span><span style="font-size:small"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 19, 2015 at 12:34 PM, Sereysethy TOUCH <span dir="ltr"><<a href="mailto:touch.sereysethy@gmail.com" target="_blank">touch.sereysethy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hello,<br><br>I just recently updated Erlang to latest version OTP 18 on Ubuntu server. It uses cowboy (websocket), ranch, ssl, erlydtl & rabbitmq. It used to work fine in OTP 17. The program is correctly compiled but during the execution the memory kept increasing. I need to restart the process every one or two hours to free some memory.<br><br>I have read a post here [<a href="http://erlang.2086793.n4.nabble.com/R18-Unbounded-SSL-Session-ETS-Table-Growth-td4713697.html" target="_blank">http://erlang.2086793.n4.nabble.com/R18-Unbounded-SSL-Session-ETS-Table-Growth-td4713697.html</a>] which discussed about the ssl_session_cache ETS table which can become very large.<br><div><br></div><div>The process beam.smp can go up to more than 5G during a few hours of executions.</div><div><br></div><div>I am not yet sure what is the root cause of this issue.</div><div><br></div><div>Does anyone know how to fix this? Or where should I look at?</div></div></blockquote><div> </div></div></div><div class="gmail_extra"><br></div></span><div class="gmail_extra">We just experienced the same after upgrading from 17.0 (leaking over days/weeks) to 17.5.3 (leaking over hours). I should be able to share some data in a few of days.<br></div></div></blockquote><div><br></div><div style="font-size:12.8px"><div>As promised, attached is a screenshot of memory usage (in bytes) before and after upgrade to</div><div>18.1 (from 17.5, on Oct 2nd at 15:00ish). This is a machine with constant load, that does not much</div><div><span style="font-size:12.8px">but poll over https every 15 seconds.</span></div><div><br></div><div>Top plot is total memory used by VM.</div><div><br></div><div>Middle is memory usage aggregated by process origin (name, if registered,</div><div>otherwise its spawn history (init call, otp init call, otp ancestry)).</div><div><br></div><div>Bottom is reductions per process origin (same schema as above).</div></div><div style="font-size:12.8px"><br></div><div><span style="font-size:12.8px">Those, pre-18.1-upgrade, sharp drops are VM deaths (restarted by upstart).</span> </div></div><br></div></div>