[erlang-questions] how to debug memory leaks?

Alain O'Dea alain.odea@REDACTED
Sat Dec 4 15:10:15 CET 2010

appmon:start() can be used to profile an OTP application and it's
constituent processes at runtime.

It is normal for the heap to increase over time.  AFAIK, Erlang GC
occurs rarely unless a process dies or memory is low.  This is similar
to how Java's GC works.  It is not unusual for a JVM to gradually
consume more memory as it runs without indicating a memory leak.

Gradual memory consumption increases are harmless so long as GC can
reclaim them.  Testing for this can be tricky.  I would create a list
big enough to trigger GC in a separate process and see if GC reclaims
the memory from the process whose heap I am monitoring.

The obvious culprits for memory leaks in Erlang for me have been:
- creating atoms dynamically
- storing large structures in the process dictionary
- behavior state data grows unboundedly (storing a growing list or
proplist for example)
- large binaries are shared across processes under the hood

The obvious fixes for me have been:
- avoid dynamically creating atoms (use list_to_existing_atom/1 or
- avoid using the process dictionary (make sure to clear keys you no
longer need if you do use it)
- avoid growing behaviour state (use a persistence solution like Riak)
- avoid large binaries

On Saturday, December 4, 2010, mabrek <mabrek@REDACTED> wrote:
> Hello.
> I've got an erlang process that seems to leak memory. It's heap size
> increases slowly over time. Are there any tools to examine process
> heap content in runtime?
> In Java I can get a heap dump of running JVM and analyze it later with
> number of tools. It shows full content of application memory.
> Regards,
> Anton Lebedevich.
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED

More information about the erlang-questions mailing list