[erlang-questions] erlang woes
Arun Suresh
arun.suresh@REDACTED
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
-but-
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 !!
-Arun
On Thu, Aug 5, 2010 at 3:42 AM, Attila Rajmund Nohl <attila.r.nohl@REDACTED
> wrote:
> 2010/8/5, Joe Armstrong <erlang@REDACTED>:
> [...]
> > 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:erlang-questions-unsubscribe@REDACTED
>
>
More information about the erlang-questions
mailing list