Code memory size different from dev to prod

Questions / Help
,
1

I have been running 1.15 locally for a while and 1.14 in production. I just upgraded production to 1.15.7 and noticed that the “code” size is different between dev/prod. I’m not sure what the expected behaviour is nor do I know what “code” memory means. I’m naively assuming it’s the size of the beam file AST in memory? Is this supposed to be static based on the deploy size or something else entirely? Erlang manual says:

https://www.erlang.org/doc/man/erlang#memory-1

The total amount of memory currently allocated for Erlang code. This memory is part of the memory presented as system memory.

So I would have assumed prod < dev actually. Anyone have any idea why this is different between dev / prod? Screenshots below.

Locally, 1.15.7 and OTP 26 gives 30MB of code size.

image
image1200×612 38.2 KB

But on production, we have 48MB of code in memory.

image
image1147×635 39.4 KB

Edit:
Also, a sidenote, trying to search for what memory code netted me this awesome post by @hauleth :rofl:

Also, an interesting note about binary memory:
http://erlang.org/pipermail/erlang-questions/2016-September/090173.html

2

Releases default to preloading all modules, mix defaults to loading modules on demand to increase startup performance in favor of slightly slower first time response when a new module is used. That‘s likely the difference you see between prod and dev.

6 Likes
3

Thanks, I did not realize that.

https://hexdocs.pm/mix/Mix.Tasks.Release.html

says code preloading is enabled by default, but there doesn’t seem to be a way to disable it?

I’m trying to tune the base memory configuration to be as low as possible, “code” should probably be 30MB even after loading everything, not 50MB.

4

If you want to lower memory footprint you likely want to cut out what you don’t need – not disable preloading. What you actually need will eventually be loaded, so your footprint wouldn’t actually get smaller.

1 Like
5

True. Perhaps my assumptions are wrong again.

I am assuming that it loads only the required functions dynamically. The example given to show why to preload was for Enum.map.

1.15 enabled code pruning, so I also assume that is the function, not module level?

Then on disk the beam files only take 30MB, but code. taking 50MB. :thinking:

Suffice to say, I don’t understand the internals. :sweat_smile:

6

Search for RELEASE_MODE in the docs. :slight_smile: interactive mode was slower to boot but that’s not necessarily the case from Erlang/OTP 26.

3 Likes
7

There is no automatic prunning of modules or functions. The feature added in 1.15 is around code paths, which brings mix projects closer to how releases are built by excluding everything but explicit dependencies mostly to otp applications. Previously all of OTP would be available for loading on demand.

To get a smaller codebase you’d need to lessen the (number of) applications you depend on, as there’s also nothing manual for pruning code at the module or function level.

1 Like
8

Thank you @LostKobrakai @josevalim .

Code path pruning
I had skipped a rather important word when reading about code path pruning.

Code memory usage
Turns out running mix release.init creates rel/env.sh.eex which has the RELEASE_MODE option right at the top . I migrated from distillery, so it wasn’t obvious what I was looking for. Anyone starting off with a fresh project would easily find this option.

rel/env.sh.eex

# # Set the release to load code on demand (interactive) instead of preloading (embedded).
# export RELEASE_MODE=interactive

Also, this may not affect startup time in OTP 26.

Final results
Using interactive mode after going thru all the routes has reduced the memory:

image

Production is running at 23MB right now, but I expect it will grow to at least 30MB. Embedded mode which preloads everything had code memory usage at 48MB. Super-helpful when running on lower memory nodes. A MB saved is a MB earned. :slight_smile:

1 Like