[erlang-questions] Garbage collection tuning for long living processes

[Jachym Holecek]

# Joel Reymont 2011-10-21:
> erlang:garbage_collect() -> true
> 
>     Forces an immediate garbage collection of the currently executing process.  The  func-
>     tion  should  not  be used, unless it has been noticed -- or there are good reasons to
>     suspect -- that the spontaneous garbage collection will occur too late or not at  all.
>     Improper use may seriously degrade system performance.
> 
>     Compatibility  note: In versions of OTP prior to R7, the garbage collection took place
>     at the next context switch, not immediately. To force a context switch after a call to
>     erlang:garbage_collect() , it was sufficient to make any function call.

Or just split memory-intense tasks into separate short-lived processes.
There's for instance no reason why session setup should be done by the
same Pid as regular request processing, and the trickier the protocol
is, the more likely it is that breaking processing into small pieces
is a good idea I'd say.

SMPP is a good example, reading the spec one would be tempted to naively
put everything into one huge FSM (there are 4 ways to setup a session!),
but it's actually saner to have some 3-4 different processes deal with
different stages of session lifetime. IIRC the authors of OTP Diameter
stack have made similar observation.

There could be cases where this is not reasonably possible of course,
but it's worth mentioning as a general pointer.

BR,
	-- Jachym