[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
binary_to_existing_atom/1)
- 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