hubertlepicki
I’ve got some requests misbehaving, and processes handling them suddenly allocate a lot of memory, which can crash my Beam VM.
I can monitor and detect that, I can also enforce max memory usage by process, that’s not an issue.
I would like to, however, know what is eating up the memory. Ideally I’d be able to take a snapshot of memory used by current process, have it dumped to a file that contains Erlang terms, which later I could analyse and find out what’s on stack, what’s on heap etc.
Is there something out there I can use to achieve that?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 24 to 15- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
garazdawi
That is true. However, since you cannot loop without calling functions I’ve very rarely found that to be a limiting factor.
hubertlepicki
I tried recon_trace - but it seems to be able to trace function calls only, not giving me any insight into what happens within functions themselves?
garazdawi
Why not use tracing for this? Seems like a perfect fit.
hubertlepicki
Yeah, so I was trying to figure out what the library I use is allocating. And I’m not super familiar with the library internals, would be just good to have a snapshot at some point and look at the terms it creates, run some function again and see what’s been allocated more etc., basically to find what causes the bloat.
I have ended up doint precisely that but on a fork of library basically printing out the terms to file with
File.write! :erlang.term_to_binary(some_variable)and then analysing that to figure out which terms are being duplicated unnecessarily.garazdawi
no, not at the moment.
arnomi
Is there a way to get the information of
:erlang.system_info(:procs)for only a single process/port?sasajuric
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.
garazdawi
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.
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
sasajuric
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:
In case you don’t know which process is the offender, you might also need to include
:initial_calland:registered_name(both available viaProcess.info).Coupled with the knowledge of the code, this should help you narrow down the problem.