It tells you only how much memory is consumed by a process.
I doubt there will be anything that tells you the actual what.
NobbZ
hubertlepicki
Alright. The closest thing to what I want to do would be crashing the Erlang VM and producing a dump file that I could analyse but that’s pretty scary thing to do on a production environment, also the resulting dump will not be scoped to the process I identified but to the whole VM (which can be a good or bad thing depening on how you look at it).
0
arnomi
There are a few things you can do. Observer (and observer_cli) allow you to inspect what processes are currently doing. In observer_cli, if you ordered the processes by memory usage and you want to inspect the first one, simply press 1. You can then, for example, inspect the messages of the process or its state.
The same you can do also from iex. To get the state of a process use sys.get_state(pid). And via Process.info(pid) (or better Recon.info(pid) which disables some of the unsafe inspections) you can look into, for example, current stacktrace, process dictionary, messages etc.
0
arnomi
I would say, this is never necessary if you already know which process is causing the issue. As mentioned above, you can first start digging into the exact process. One thing to also look into, is garbage collection. You can use :erlang.garbage_collect to force garbage collection for processes. Especially if the process is long running, tuning garbage collection may be necessary.
1
sasajuric
Author of Elixir In Action
AFAIK, it’s not possible to get what you’re looking for out of the box. To get some clues, you could use a combination of the following:
- memory usage of the process
- process stack trace
- message queue length
- total binary memory usage
- total ETS memory usage
In case you don’t know which process is the offender, you might also need to include :initial_call and :registered_name (both available via Process.info).
Coupled with the knowledge of the code, this should help you narrow down the problem.
2
hubertlepicki
Right, but if a process is not a nice member of OTP family, as in it’s a Cowboy protocol handler (i.e. process in which Phoenix’s web requests are being handled), and memory is being allocated within the same process there is nothing that will give me insight to the allocated memory. That’s sad, I know Java has tools that can do precisely that, it’s a shame we don’t have the same 
0
garazdawi
Erlang Core Team
Maybe :erlang.system_info(:procs) is closer to what you are looking for? From it you can get the values that are currently live on the stack.
1
sasajuric
Author of Elixir In Action
The stack trace should help you narrow down the problematic code. We actually had a similar situation recently, and we ended up periodically logging the processes with unusually high mem usage, together with their stack traces. In this particular situation that info was enough to completely understand the root cause. I agree that it’s not quite what you’re looking for, but it can help you in understanding the problem.
It’s also worth keeping in mind that in a general case excessive mem usage can be caused by other things, such as messages accumulated in the process queue, or refc binaries, or ets tables, so finding the cause is not necessarily as straightforward as logging the current heap of the process, which is why I mentioned a couple of different things in my previous answer.
3
arnomi
Is there a way to get the information of :erlang.system_info(:procs) for only a single process/port?
0
garazdawi
Erlang Core Team