Memory allocator limits for low‑traffic Erlang workloads

The primary goal is to keep the memory footprint of a low‑traffic Erlang node minimal so that hosting costs can be reduced. Erlang’s lightweight processes normally require roughly 1.5 KB of heap, but the default runtime allocator (erts_alloc) can over‑allocate for short‑lived processes, inflating the resident set size on nodes that handle only a handful of concurrent processes.

Switching to the atomics allocator via the +M flag improves fragmentation and can lower the overall memory usage. However, this change may increase process spawn latency and alter garbage‑collection behavior, potentially hurting the responsiveness of the application. The trade‑off between fragmentation, memory usage, and spawn performance is not fully documented for low‑traffic scenarios.

Because the cost‑to‑performance balance is unclear, the choice of allocator remains an unresolved decision for cost‑constrained, low‑traffic workloads.

Key questions for investigation:

• How does erts_alloc compare to atomics in terms of total resident memory on a node with <10 concurrent processes?
• What is the measurable impact on process spawn latency and GC pause times when using atomics versus erts_alloc?
• Are there documented thresholds or guidelines that recommend a particular allocator for low‑traffic deployments?