Memory Analysis & Garbage Collection Tuning

Erlang nodes can run for months. A small per-process leak or unbounded mailbox grows silently until the node is killed by the OS. Observability into memory is essential.

erlang:memory/0 returns a breakdown: total, processes, atom, binary, ETS and more. Watch the categories that grow over time.

process_info/2 reveals a single process heap, message queue length and more — key for finding the culprit.

If a process receives faster than it handles, its mailbox grows without bound. A large message_queue_len is the classic sign of an overloaded consumer.

Large binaries are reference-counted and shared off-heap. A process holding a tiny sub-binary can pin a huge parent binary. Watch the binary memory category closely.

Sort all processes by memory to find leaks fast.

Each process has its own private heap and is garbage-collected independently — there is no global stop-the-world pause. Collection runs when a process heap fills.

For a process you suspect is holding garbage, force a collection and re-measure.

Spawn options like min_heap_size and fullsweep_after tune GC for hot processes, trading memory for fewer collections.

Idle processes can call hibernate to compact their heap to the minimum, freeing memory until the next message arrives — great for many mostly-idle connections.

ETS tables live outside process heaps and do not shrink automatically. A growing ets memory category often means stale rows; periodically prune or use tables with a bounded size.

Test your memory tuning knowledge.

You learned to analyze and tune memory:

• erlang:memory/0 gives a system-wide breakdown
• process_info/2 inspects per-process heap and mailbox
• Growing mailboxes and pinned binaries are common leak sources
• Each process is GC-ed independently; no global pause
• Tune with spawn options and use hibernate for idle processes