<div dir="auto"><div>Hi Dmitry,<div dir="auto"><br></div><div dir="auto">if I remember correctly, the embedded mode loads all code for the required applications of your system, whereas interactive loads modules as required. The embedded approach has the benefit of knowing exactly how much memory your code takes up. As well as moving the loading to the start.</div><div dir="auto"><br></div><div dir="auto">For specialist systems, you could create cut down versions of your applications to only include the modules you are actually using. You are likely to need all of kernel, but beyond that there is scope for minimization ☺</div><div dir="auto"><br></div><div dir="auto">No idea though why embedded mode would be default for relx. Personally, unless I had good reason to otherwise, I'd always opt for interactive. Biggest downside is missing code you only get told about late. </div><div dir="auto"><br></div><div dir="auto">Hope this helps,</div><div dir="auto">Robby</div><div dir="auto"><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">On 10 Jul 2017 18:23, "Dmitry Kolesnikov" <<a href="mailto:dmkolesnikov@gmail.com">dmkolesnikov@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I’ve never raise a memory concern for Erlang application in the cloud. Recently, I though to fit as many independent Erlang releases as possible into cloud container cluster (AWS ECS). The memory is one of the dimension you have to control and provision, you need to declare application initial RAM and reserve its expansion.<br>
<br>
Reading the Erlang documentation<br>
<a href="http://erlang.org/faq/implementations.html" rel="noreferrer" target="_blank">http://erlang.org/faq/<wbr>implementations.html</a><br>
<br>
"People successfully run the Ericsson implementation of Erlang on systems with as little as 16MByte of RAM. It is reasonably straightforward to fit Erlang itself into 2MByte of persistent storage (e.g. a flash disk)."<br>
<br>
The VM claims significant amount of `system` memory when release is booted with embedded code loading strategy.  For example a simples web echo server might require up to 45MB of memory with total initial memory budget for the application over 50MB. The interactive code loading strategy relax `system` memory consumption to 18MB with total application budget under 32MB. The `system` memory do not grow significantly (+/- 5MB) during the life cycle of this application.<br>
<br>
Here is some questions<br>
<br>
* Why there is such huge difference of system memory usage between embedded and interactive code loading strategy? It seems to me that embedded model load almost OTP libraries into memory even half of them are really used in the application?<br>
<br>
* The default code loading strategy is interactive for OTP but relx makes it embedded. Why?<br>
<a href="https://github.com/erlware/relx/blob/master/priv/templates/extended_bin#L37" rel="noreferrer" target="_blank">https://github.com/erlware/<wbr>relx/blob/master/priv/<wbr>templates/extended_bin#L37</a><br>
<br>
* What is your experience to use interactive code loading in the CLOUD production systems? Frankly speaking, I’ve always used embedded mode.<br>
<br>
* Do you see an other techniques to reduce memory consumption besides 32-bit system and half-word emulator?<br>
<br>
Best Regards,<br>
Dmitry<br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div></div>