VM with 32MB RAM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

VM with 32MB RAM

Dmitry Kolesnikov-2
Hello,

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.  

Reading the Erlang documentation
http://erlang.org/faq/implementations.html

"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)."

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.  

Here is some questions

* 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?  

* The default code loading strategy is interactive for OTP but relx makes it embedded. Why?
https://github.com/erlware/relx/blob/master/priv/templates/extended_bin#L37 

* What is your experience to use interactive code loading in the CLOUD production systems? Frankly speaking, I’ve always used embedded mode.

* Do you see an other techniques to reduce memory consumption besides 32-bit system and half-word emulator?    

Best Regards,
Dmitry
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: VM with 32MB RAM

Robert Raschke
Hi Dmitry,

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.

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 ☺

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. 

Hope this helps,
Robby



On 10 Jul 2017 18:23, "Dmitry Kolesnikov" <[hidden email]> wrote:
Hello,

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.

Reading the Erlang documentation
http://erlang.org/faq/implementations.html

"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)."

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.

Here is some questions

* 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?

* The default code loading strategy is interactive for OTP but relx makes it embedded. Why?
https://github.com/erlware/relx/blob/master/priv/templates/extended_bin#L37

* What is your experience to use interactive code loading in the CLOUD production systems? Frankly speaking, I’ve always used embedded mode.

* Do you see an other techniques to reduce memory consumption besides 32-bit system and half-word emulator?

Best Regards,
Dmitry
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: VM with 32MB RAM

Tristan Sloughter-4
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 ☺

Right, you can use `exclude_modules` in the relx config to achieve this.

As for why it defaults to embedded, this is simply because in a release you've built for your project it is expected you have included only what is needed. Interactive is important for say running the shell during development because you don't want to load the entirety of OTP everytime you pull up `erl`. When that isn't an issue why push load time to when the code is actually called in production instead of getting it done up front.

Tristan

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: VM with 32MB RAM

Dmitry Kolesnikov-2

On 10 Jul 2017, at 21.15, Tristan Sloughter <[hidden email]> wrote:

As for why it defaults to embedded, this is simply because in a release you've built for your project it is expected you have included only what is needed. 

How does it make a decisions what is needed? As far I re-call, it is made at high level only. If you app uses application A that use B and C then all apps are included into release and their code is loaded into memory  even if feature of A that uses C is not ever called from my application, right? or it appliance heuristic and pick only the modules that definitely used by the application (in this case C will not be ever included into release)? 

- Dmitry   


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: VM with 32MB RAM

Tristan Sloughter-4
It is done by the applications list in the .app files. It isn't possible to check that C will never be used in your example. xref can probably used to find some cases. But it is up to the user to add to the relx config `{exclude_apps, [C]}` which tells relx to not only not include C but also remove C from any .app file that had it listed.

--
  Tristan Sloughter
  "I am not a crackpot" - Abe Simpson


On Mon, Jul 10, 2017, at 11:24 AM, Dmitry Kolesnikov wrote:

On 10 Jul 2017, at 21.15, Tristan Sloughter <[hidden email]> wrote:

As for why it defaults to embedded, this is simply because in a release you've built for your project it is expected you have included only what is needed. 

How does it make a decisions what is needed? As far I re-call, it is made at high level only. If you app uses application A that use B and C then all apps are included into release and their code is loaded into memory  even if feature of A that uses C is not ever called from my application, right? or it appliance heuristic and pick only the modules that definitely used by the application (in this case C will not be ever included into release)? 

- Dmitry   



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: VM with 32MB RAM

Tristan Sloughter-4
A little fish told me another benefit of embedded mode just now.

In embedded mode there is no code server lookup for an undefined function. So a system that makes use of catching an undef will not be happy once under load and in interactive mode.

--
  Tristan Sloughter
  "I am not a crackpot" - Abe Simpson


On Mon, Jul 10, 2017, at 11:31 AM, Tristan Sloughter wrote:
It is done by the applications list in the .app files. It isn't possible to check that C will never be used in your example. xref can probably used to find some cases. But it is up to the user to add to the relx config `{exclude_apps, [C]}` which tells relx to not only not include C but also remove C from any .app file that had it listed.

--
  Tristan Sloughter
  "I am not a crackpot" - Abe Simpson


On Mon, Jul 10, 2017, at 11:24 AM, Dmitry Kolesnikov wrote:

On 10 Jul 2017, at 21.15, Tristan Sloughter <[hidden email]> wrote:

As for why it defaults to embedded, this is simply because in a release you've built for your project it is expected you have included only what is needed. 

How does it make a decisions what is needed? As far I re-call, it is made at high level only. If you app uses application A that use B and C then all apps are included into release and their code is loaded into memory  even if feature of A that uses C is not ever called from my application, right? or it appliance heuristic and pick only the modules that definitely used by the application (in this case C will not be ever included into release)? 

- Dmitry   


_______________________________________________
erlang-questions mailing list


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions