mattei
Hi all, big Elixir fan (and newbie!) dropping by to ask something that has been puzzling me for a bit.
I’m building an app that relies on Oban for job processing. However, some jobs are getting killed/crashing with obscure errors by the BEAM.
These are the strange behaviors:
-
Oban job gets killed. The Oban job is simple, it only does an HTTPoison request.
-
Requests/responses seem to get stalled. HTTP requests take too long/forever, although the actual time elapsed doesn’t reflect in the response time metric in terminal.
Request gets stalled early in the plugs process, then after a few second resumes:
When it happens (all local, not production):
- High request rate – sending tons of requests, Oban job inserts from Postman into the API endpoint
- Suspected high memory pressure – although I doubt it’s OOM, because I’ve looked at activity monitor and sometimes it happens, even in the green.
- Randomly – sometimes I’m only sending a one off request
Here are some suspicions:
- Too many queries being sent, Postgres stalling.
- Out of memory/low resource behavior, but I thought BEAM handled this better.
- Oban job taking too long, although it’d be a TimeoutError, not a Killed.
- Infinite recursion somewhere, although I feel that’d also be a TimeoutError from Oban.
- HTTPoison bug, the process gets killed.
- Memory leak.
I have no leads other than these error messages and strange behavior.
Where would I start to debug this problem? How would I prove any of these theories? I’m new to the BEAM and it’s very different from a traditional language.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
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
- #metaprogramming
- #hex
- #security
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.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Marked As Solved- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
benwilson512
No, the whole VM is unloading the code that was there before, and then loading the new compiled code. The best thing to do is just let Oban retry the job after the crash.
Also Liked
lud
Your process receives and :EXIT message from another process that is linked to the former.
Do you start a process from your job process with a
SomeModule.start_linkorspawn_linkcall? The process with pid <0.13246.0> was killed and as it was linked to your own process, your process exited with that same reason.You may create a test and directly call your
Job.performfunction repeatedly, without starting oban. This will be easier to get a proper stacktrace.emoragaf
normally you would wait for a connection to become available, but when you have the issue of having the connections not being released back into the pool you basically loose capacity silently until things blow up.
The worst thing is that since it’s very easy to just leave the :default pool, you can have totally unrelated parts of your app (that also use the default pool) causing this issue.
This kind of thing could indeed be the root cause of pool starvation, to the point where you have your jobs waiting forever for a connection that is never going to be put back into the pool
benwilson512
Hey @mattei as a couple of notes, please always copy and paste text instead of using screenshots. Those screenshots are barely visible on my screen due to resolution / saturation.
Secondly, when you say “hot reloads” are you referring to development code reloading, or are you using OTP hot reloading in production?
Last Post!
mattei
UPDATE: I’m getting tons of Postgrex.Protocol client exits, not sure what’s going on – the local server seems to completely crash and hangs all requests.
I’m not doing any particularly long-running queries. Is there any way to get further stacktraces for these exits?