dcrck
Agent keeps large binary memory despite no state
Hello,
I’m having some trouble optimizing the memory usage for my application. Its job is manage and collect data from a bunch of networked devices (typical IOT application).
I create a process for each managed device (via DynamicSupervisor) that handles communication and data retrieval. I send the data (a map) to an Agent process that accumulates the data in a giant map of device address => device data. Once every few seconds, another process grabs this accumulated data (if present), encodes it with JSON.encode!/1 and publishes it on MQTT. When the data retrieval happens, the Agent resets its internal state to an empty map via get_and_update.
This works fine, but for whatever reason the agent accumulates binary memory over time. :recon.proc_count(:memory, 10) shows its memory constantly increasing, even though the data it collects should be temporary. I can call :recon.bin_leak/1 to clear the memory out, but I’d rather find out what’s causing the constant memory increases. For reference, the number of devices is less than 1000 and the data accumulated for each device can be enough to push the outgoing encoded message to ~1MB.
What might I be doing incorrectly here? I’d rather not run garbage collection manually, but I can do so if necessary. Thanks!
Marked As Solved
dcrck
Yeah, I’m using :observer and :recon to help figure out where the memory is growing. It’s definitely process heap memory that’s expanding due to large refc binaries I was passing around like it was free. Lesson learned, I guess.
I’ll see if I can move most of the stuff dealing with large binaries into short-lived/temporary processes that I spawn when I get a new control message. For the longer-running device processes that interact with the large binaries, I’ll try manually garbage collecting those after sending the data along to ETS tables (instead of an Agent for distributed writes), then delete/shutdown the temporary stuff once all data has been processed in a given cycle.
Will try this tomorrow and see how it goes.
Also Liked
sodapopcan
So nice to see a topic with the word “Agent” in it that is actually referring to the OG ![]()
I know it’s not actually the OG, I’m speaking contextually, jeez
Lucassifoni
But what do you do while your agent is garbage collecting ?
More seriously, :observer is useful to me in those binary leak cases.
Asd
refc binary means that there is actually only one global instance of a binary kept in memory and all these processes are just referencing it. It is an optimization.
The other problem is sub-binaries. It is a parsing optimization, when we want to extract a part of binary in a new binary, runtime actually just create a reference inside this bigger binary, thus keeping the bigger binary in memory. This is solved by :binary.copy and it is true only if you extract your machine information from large strings with some specific operations, but again, using :binary.copy is an optimization which makes garbage collection a bit more efficient
can probably make the change to call
eval “:erlang.garbage_collect”
Garbage collection in BEAM is local to the process. Calling :erlang.garbage_collect clears the memory only in the calling process
Popular in Questions
Other popular topics
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
- #javascript
- #code-sync
- #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
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








