tj0
Code memory size different from dev to prod
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:
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.
But on production, we have 48MB of code in memory.
Edit:
Also, a sidenote, trying to search for what memory code netted me this awesome post by @hauleth 
Also, an interesting note about binary memory:
Marked As Solved
tj0
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:
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. 
Also Liked
LostKobrakai
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.
josevalim
Search for RELEASE_MODE in the docs. interactive mode was slower to boot but that’s not necessarily the case from Erlang/OTP 26.
LostKobrakai
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.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"