chasers
Any insight would be appreciated here…
I’m getting this message in my logs and can’t quite figure it out:
Postgrex.Protocol (pid<>) disconnected: ** (DBConnection.ConnectionError) client pid<> exited
I’ve been working on a centralized logging service https://logflare.app. It’s really easy to start using if you’re on Cloudflare because we have a Cloudflare app. Recently been getting some larger sites signing up.
This weekend we got another big one playing with it. CPU was high and ram started climbing. Looking at the logs I see that message.
At that point everything was on a $40 a month Digital Ocean box (which is awesome because we are handling a lot of requests, sometime sites are sending upwards of 1000 requests a second). No downtime at all and no bad response codes. Ecto seems to just be reissuing the query or something if it exits.
My first try at alleviating this was to move Postgres to it’s own instance. I did that … still seeing errors. Doesn’t seem to be Postgres struggling. Upped the Ecto pool count, and enabled pooling on Postgres. No difference there.
Then I started caching API keys in ETS. Which is also awesome because it was super easy. A little lighter load on Postgres but still I get those errors in the logs.
Not quite sure where to go from here. The way I see it I can:
a) Cache more stuff in ETS.
b) Upgrade the box.
c) Remove Nginx as maybe there is some contention there (currently limiting Nginx to 2 workers and it’s a 4 core box).
Although I’m still kind of just throwing darts here. Is something in my code killing the client? Is whatever making that call finishing before the query returns and causing the exit?
I need to figure out how to run observer remotely. Maybe that will shed some light on things. I’m assuming the ram issue is logger filling up with error messages.
Another fun side effect is that mix edeliver restart production just hangs. No idea why that is either.
Code is all up at: GitHub - Logflare/logflare: Never get surprised by a logging bill again. Centralized structured logging for Cloudflare, Vercel, Elixir and Javascript. · GitHub
Trending in Questions
Other Trending 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
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
engineeringdept
You’re not running on Erlang/OTP 21.3 are you? I got bitten by this bug, when connecting to Postgres over SSL.
outlog
yeah, this(similar error output)was also in an earlier OTP (20).. so make sure to bump to latest patch version - and avoid 21.3
chasers
Running OTP 21 will by a different patch version
outlog
what version are you on now?
chasers
Did
sudo apt-get upgrade esl-erlang=1:21.2.7-1and still seeing this issue.Upgrade looks like it went fine. Killed and restarted the app. Maybe recompile?
chasers
And come to think of it … it was happening before when Postgres was on the same server and I wasn’t connecting over ssl.
outlog
can you post a bit more of the error log eg. is an timeout?
would assume you need to do a new release to pick it up - also update your build server..
also mix.hex outdated has latest postgrex/ecto etc?
EDIT: also what OTP version did you have on it?
chasers
Logs just look a lot like this:
deps are:
Build server is currently the same as prod.
outlog
Those logs are missing key information… but I will go ahead and assume those are timeouts..
I assume “POST /api/logs” to be a flaming hot path and from a quick look you have 5-7 db queries going on that is way much for a hot path (starting with a plug assigning user which seems not needed)
increase the ecto :timeout
consider using Repo.checkout to bundle them into one, but perhaps better to use Cachex and avoid the db calls.
they look like somewhat stable repo.get/repo.all - so wrap those calls with Cachex - add appropriate cachex update/delete calls where needed elsewhere to bust/update the cache.
consider instrumentation like GitHub - deadtrickster/prometheus-ecto: Prometheus.io collector for Elixir.Ecto · GitHub or similar
chasers
Yeah untangling those queries from there was definitely my next idea.
I thought about the timeout but none of them seem to be running long:
And from what I read elsewhere you’d normally see a timeout message with the error.
Anyways, much appreciated. I will rewrite the logs stuff with some caching and go from there.