[erlang-questions] Garbage collection tuning for long living processes
Joel Reymont
joelr1@REDACTED
Fri Oct 21 13:09:28 CEST 2011
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.
On Oct 21, 2011, at 11:56 AM, Jonas Boberg wrote:
> Hi,
>
> We have an Erlang server with tens of thousands of medium/long living
> processes. Each of these processes handles a TCP connection. The
> Erlang VM garbage collector does not size the heap of these processes
> to our liking. This seems to be due to the memory allocation pattern:
> * The processes initially (during connection setup) need a lot of
> memory - sometimes up to several megabytes. The VM (correctly) grows
> the heap of the process, typically we see a heap_size of 514229 or
> 319408.
> * After the connection setup, the processes need relatively little
> memory, typically less than one kilobyte.
> * At random intervals after connection setup, the process needs a
> medium amount of memory (100s of kilobytes) for a short time, and then
> goes back to the low allocation pattern.
>
> The heap is never down-sized. Looking at the GC code in VM, I think
> this is because a GC is not run until a allocation requires more
> memory than available on the heap. It takes hours for this to happen,
> since the heap initial grows to several megabytes, and little memory
> is allocated.
>
> Things tried:
> * Setting the spawn option {fullsweep_after, 0} - does not improve
> the situation. Since garbage collection doesn't occur, neither does a
> fullsweep.
> * Hibernating the process after every handled client request. While
> this minimizes the heap size, it increases CPU usage significantly.
> The thing is that the processes aren't going inactive, so they are
> constantly waked up from hibernation as messages are passed to them.
> We don't really have a good criteria of when to hibernate.
>
> Are there any other tuning parameters in the VM that might help us?
>
> Regards
> Jonas
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
--------------------------------------------------------------------------
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
---------------------+------------+---------------------------------------
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
---------------------+------------+---------------------------------------
More information about the erlang-questions
mailing list