Jonathan Skogeby
Jonathan Skogeby

Reputation: 83

Ruby on Rails & Heroku - "Too many connections for role"

I am running a rails app on Heroku hobby-basic plan and for some reason I keep getting the infamous "Too many connections for role " error whenever I try to connect to the production database. This means automated backups keeps failing and rake tasks won't run because they are denied connection.

Every time I run heroku pg:info it says 20/20 connections. If I run heroku pg:killall then all connections are killed and it says 0/20 until I restart all dynos and it instantly goes back to 20/20.

I managed to run heroku pg:psql by killing all connections and restarting the server to trigger the connection leak. Running SELECT * FROM pg_stat_activity reveals many idle "SELECT 1" queries but not where they come from. Here is a typical row limited to application_name, client_addr, waiting, state and query:

bin/rails | 10.14.19.163 | f | idle | SELECT 1

Now imagine that x20, all started milliseconds between each other. The staging-app does not show these symptoms and is constantly at around 1/20 connections.

This all started after a fairly large but ordinary deploy from staging to production (basically just adding some new views, models, controllers, precompiled assets, etc).

Any help debugging this mess would be greatly appreciated.

EDIT:

database.yml

default: &default adapter: postgresql encoding: unicode pool: 5 production: <<: *default url: <%= ENV['DATABASE_URL'] %>

heroku ps says the following:

=== web (Hobby): bin/rails server -p $PORT -e $RAILS_ENV (1) web.1: up 2018/08/11 23:10:04 +0200 (~ 13h ago)

Upvotes: 0

Views: 1238

Answers (1)

Alex.U
Alex.U

Reputation: 1701

This could be cause by a few things. One of them could be if you're using a concurrent web server like Puma, it could be getting that many connections when deployed in production.

A way to debug this is starting your application in production mode:

rails server -e production

And in your database check the number of connections

select * from pg_stat_activity

And check which process is taking connections. If the problem remains considering using a connection pool PgBouncer

Upvotes: 0

Related Questions