I have deployed a Rails app on Heroku since 2 years without trouble
Todays the app crash.
Rails log are:
/app/vendor/bundle/ruby/2.3.0/gems/pg-0.21.0/lib/pg.rb:56:in `initialize': FATAL: sorry, too many clients already (PG::ConnectionBad)
FATAL: sorry, too many clients already
My rails app is v5.2.0
I use Heroku with 2 dyno
The database is a postgres with "Hobby Dev".
I try:
To upgrade the database but I got the same error
heroku addons:create heroku-postgresql:standard-0 --follow DATABASE_URL --app locabri
Creating heroku-postgresql:standard-0 on ⬢ xxxx... !
▸ An error was encountered when contacting the add-on partner to create heroku-postgresql:standard-0: The database you are attempting to follow was not found.
to change DB_POOL in env variable
heroku pg:info
=== DATABASE_URL
Plan: Hobby-dev
Status: Available
Connections: 0/20
PG Version: 10.6
Created: 2017-05-29 07:40 UTC
Data Size: 138.8 MB
Tables: 12
Rows: 5748/10000 (In compliance)
Fork/Follow: Unsupported
Rollback: Unsupported
Continuous Protection: Off
Region: Europe
Add-on: postgresql-regular-79163
But nothing work.
I can't do anything on the database because I can't connect on it and and don't know how to restart it.
Thanks for your help or question
EDIT
heroku pg:killall
doesnt work
SOLUTION
I finally find the solution by changing the available dyno !
heroku ps:scale web=0
heroku ps:scale web=2
heroku restart
Now I can check the "connexion leak"
Recently I encountered a the same error message for one of my Python apps. I've reached out to Heroku and they acknowledged the error:
FATAL: sorry, too many clients already
"It is generally triggered because the hobby tier databases are a shared resource which means that several databases will share computation and storage from a host. We monitor these regularly and always aim to run them with spare capacity but occasionally coincidental spikes in usage from neighboring databases can cause the host machine to have trouble. This is one of the reasons we don't endorse the hobby tier for use in production applications."
They suggested trying one of the following options:
Provision a new hobby database on the same plan and migrate the data over. This will spin up on a new database host which will mean that you no longer have the same noisy neighbors.
Upgrade to one of the professional plans
I've not tried the 1st option, but the second one solved my issue. This answer shows you how to do the migration step by step.
Related
We are getting a lot of sentries issue with PG:ConnectionBad on Postgres in RDS AWS and Ruby on Rails
PG::ConnectionBad Sidekiq/BookingExtensionCheckWorker
could not translate host name “ls-XXXXXXXXXXXXfee44.XXXXXXXXX.eu-west-1.rds.amazonaws.com” to address: Name or service not known
In two weeks ago, we have migrate a new database and we change endpoint in the RoR files api
new database endpoint,
ls-XXXXXXXXXXXXXXXf3d4a.XXXXXXXX.eu-west-1.rds.amazonaws.com
It working fine with no issue between the new database and Ruby on Rails api. however, I get a lot of sentries issue said that sidekiq having an issue with connection database as they use old database address which it’s no longer used. I have to check sidekiq database; the code shows it’s connected to the new database. They keep go back to the old database when I run Ruby on rails.
Is there some way to find why sidekiq keep connection old database
Sidekiq is background service. So when someone deployed he has used some sort of like. Right now you are getting issue you think is fine but actually most jobs are not running. Which you will noticed in few days.
How can you check jobs If you sidekiq setup. Probably following url will lead to all jobs.
your_url/sidekiq
It will show you all jobs, I think you have option here to restart services. Just click to restart sidekiq. And everything would be fine.
How to start
As your sidekiq running with old configuration. So following steps could be dangrous, I think you must check how you have started your process. Otherwise following are some way people configure it and runt it.
systemctl restart sidekiq
If this does not work, check your command your deployment guy has setup some sort of scripts inside /etc/init.d folder
Some time developer use following simple line to run sidekiq
bundle exec sidekiq -d -P tmp/sidekiq.pid -L log/sidekiq.log
or
bundle exec sidekiqctl stop
I have a rails app which when deployed to Heroku takes 3 to 4 minutes to go live even after successful deployment. During that that period it shows error as "request timeout". I have enabled preboot as mentioned here:
https://devcenter.heroku.com/articles/preboot but still same result. I am on Heroku enterprise and still facing this issue. Please suggest what i am missing, here is the dyno and Add-ons info that i am using
I'm using Amazon instance to to run my Ubuntu server, i depyoed new feature and did
rake assets:precompile RAILS_ENV=staging
but i got error while pre-compiling
Allocation failed - process out of memory precompile
I found out that my CUP usage was 100%. I exit that proecess. But now i'm not able to SSH in to my server. The instance on AWS is running state.
it says ssh_exchange_identification: read: Connection reset by peer
Ok, It turned out I was running multiple process like sidekiq, rails console and my error logs in other terminal. So it drained a lot of RAM memory that time.This is why the server stopped responding.
I restated the Instance so i was able to log in to the SSH and then only ran precompaile and it worked. Still the memory usage was around 95% but other processes were close that time,so the precompailatoin ran successfully.
I'm using this server just as staging/testing server before production so there is no point of increasing memory(As of now). SO the above solution worked for me. Hope this might come in hand for you guys.
I'm getting the following error with Ruby on Rails, Heroku and Postgresql:
PG::Error (FATAL: too many connections for role "********"
I've restarted the server several times to no avail. Any ideas?
Paying Heroku more money isn't always the answer.
I had this problem temporarily when I was running up against the dev-level database's row limit. Deleting rows using the console until I was below the limit solved the issue.
Another potential way you can run into this is if you're using unicorn. The number of connections used is the number of dynos times the number of unicorn workers per dyno. Heroku explains it all here, along with a way to configure it in config/unicorn.rb.
Also, seeing the number of connections being used can be useful. Just run heroku pg:info.
Apparently I was on a dev-level DB. I upgraded to Crane level production DB and everything should be fine.
Considering migrating an app to Heroku. Currently we build & test locally before deploying to our own server for hosting...But the application is growing and now wondering if it's reasonable to have, say, 3 versions of our app. One local to developer's machines. A second (testing) deployed via Capistrano to an internal server. And then finally a third on Heroku (production). Databases would not need to be shared.
Any problems or advice for this sort of scenario?
I think it's a good thing to have a staging server with the same environment as your production. So instead of internal server, wouldn't it be better to test on heroku?
For this purpose I've created another app on heroku and before updating my production app, I push my app to the staging one.
I would highly recommend the heroku_san gem which simplifies pushing app to heroku to just rake staging deploy.
I do this. I have development on developer's machines, staging, and production.
Staging is our test sandbox and sometimes also shares user databases with production so I can let users beta test, etc.
Whether or not you use Heroku for production really doesn't matter does it?