That might indeed be a reason. A simple fix could be to hibernate each process after they do the work on the segment. So if it’s a GenServer, you can add :hibernate at the end of each tuple you return from handle_* callbacks (e.g. {:noreply, new_state, :hibernate}). This will lead to the GC of the GenServer and thus the references to binaries will be released.

Hibernation will cause some performance penalty, but whether that’s significant or not depends on the load on the process being hibernated.

Note that you can also use :recon.bin_leak/1 to try to find out the offending processes.

It might be faster to just do a gc, :erlang.garbage_collect(), as doing a hibernate does more work because it first packs the process together then unpacks it on the next message. I don’t know if there is an Elixir call to this function.

Are you sure? AFAIK elixir can’t support OTP 16, since maps have only been introduced with OTP 17.

The README of the 1.4.0 tag of the github repository clearly states:

(Elixir requires Erlang 18.0 or later)

Also I think I’ve seen some kind of matrix once which desc ribed which version of erlang was supported by which version of elixir, but I can’t find it right now.

Aside of that, you can create space leaks (not memory leaks) easily when creating substrings from strings that are longer 64 byte. Therefore it is considered good practice to :binary.copy/1 strings you have extracted and want to use for longer than a few moments.

As a rule of thumb I do copy every string I pass into another function.

My bad. I forgot that I include erlang VM into build, it is 19.3.
So, do you suggest to copy all strings in my map and then pass it futher?

Since I do not know whats the source of the strings in the map actually is, I can’t tell for sure. But if they are smaller parts of some huge string, copying might help.

But to be really sure, we had to see much more code.

Similar problems can occur when you steadily eat from an input binary and then hold a reference to the very last sub-binary somewhere.

And since this is a really complex matter, I pulled in 3 links, which I found randomly:

• https://www.erlang-solutions.com/blog/erlang-19-0-garbage-collector.html
• https://hamidreza-s.github.io/erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
• http://erlang.org/pipermail/erlang-questions/2012-November/070779.html

I’ve read the GC 19.0 article by myself about a year ago and it helped me a lot to understand how garbage collection and the BEAM are working. But I’m not sure anymore if the binheap was explained well there. Therefore I put the other 2 links as well.