[erlang-questions] erlang woes

Arun Suresh <>
Thu Aug 5 19:13:11 CEST 2010

Incidentally, I do use this exact same command line...

But I am more concerned about which proces actually killed the node... If
you look at the crash.dump file...
I grep on all lines with 'Stack+heap: .......' (basically all processes with
Stack+heap > 7 digits)

This gives me a fair account of which were the memory hungry processes when
the node went down


It does NOT tell me which process had made the request for the memory..
which could not be allocated.. and which brought the node down !!


On Thu, Aug 5, 2010 at 3:42 AM, Attila Rajmund Nohl <
> wrote:

> 2010/8/5, Joe Armstrong <>:
> [...]
> > I suspect this is an uncommon error - if it were common then you'd
> > find more tools
> > for detecting rogue processes in the standard libraries - their
> > absence indicates that either this
> > is not a common problem, or that it is a common problem, but resolving
> > it it easy.
> I've seen two tools that can be used to detect rogue processes. I also
> have some one-liners on the local project Wikipage. So I'd go for the
> second option: it's a common problem, but not that hard to resolve (or
> at least to find the offending process - it's rather more complicated
> to find out why it leaks and I guess it's too hard to write an
> automated tool).
> By the way, the one-liners (in case some of you find it useful):
> Which process uses the most memory:
> lists:reverse(lists:keysort(2,[{P, erlang:process_info(P, heap_size)}
> || P <- erlang:processes()])).
> Which ets table uses the most memory:
> lists:reverse(lists:keysort(2,[{T, ets:info(T, memory)} || T <-
> ets:all()])).
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:

More information about the erlang-questions mailing list