BenSchZA
Phoenix server randomly stops serving requests with no error reported
I’m running two Phoenix applications. Both of them deployed in the same manner (as far as I can see), with different purposes and corresponding packages installed. One of them, my personal website/blog, periodically stops serving requests - this appears as a “Bad Gateway” error from Traefik. The issue occurs at random - sometimes after an hour, sometimes after a few hours, or after a few days.
To troubleshoot the issue I’ve used the observer and dug through the stats - I don’t see anything obvious, and don’t see any crashdumps. The application is deployed with Docker and mix releases, but the same issue occurs when using mix releases deployed locally (definitely not a memory issue) and on the server as a systemd service. I’ve also tried different Erlang/Elixir version combinations (following guidelines).
There are no crash dumps, no out of the ordinary logs, it just stops serving requests.
I feel like I might be missing something obvious, or that there’s some other debugging technique I could use to find the issue. Perhaps there’s a package version incompatibility, but I’m not using any out of the ordinary packages. Here’s the repo for reference: GitHub - BenSchZA/phoenix-blog: Personal Phoenix Framework blog and webapp. · GitHub . The other application has been running stable for a few months: GitHub - BenSchZA/kawapi-phoenix: Phoenix LiveView frontend application and API server for KawAPI · GitHub
I appreciate any guidance and help! Let me know if there are any other details I can provide.
Marked As Solved
wanton7
I think your problem is that you are calling Cachex.expire inside fetch function and key not be created until you exit that function, It should be done this way.
From ttl option of `Cachex.fetch` · Issue #195 · whitfin/cachex · GitHub
with { :commit, _val } ← Cachex.fetch(:my_cache, cache_key, &my_func/1) do
Cachex.expire(:my_cache, cache_key, :timer.seconds(1)
{ :commit, val }
end
Also Liked
benwilson512
Hey @marschro this is likely related to a dependency and not the core language. The main thing to check is the process message queue, which is a common source of memory build up. This should be visible from the live dashboard quite easily, although I don’t know if it’s a default view from htop. I’m also a big fan of :observer_cli in terms of command line debug views.
dimitarvp
BenSchZA
Okay… don’t know why I didn’t try this before. Going to a path other than the URL root works. So clearly there’s some issue with a specific module loaded on the root endpoint. Appreciate all the suggestions! Still don’t know what the issue is, but I should be able to track it down now.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









