too many connections for role “username” heroku no

问题:

I have two sites that started receiving the too many connections for role error.

The site crashes several times a day with that error and the only thing that helps is the cli heroku pg:killall

The application releases all the connections correctly - it's a very simple and basic application that uses postgres connection pool.

When I look at the open sessions on pgadmin I see multiple connections by something called "yobuko".

As I follow it, it opens more and more connections until it reaches the 20 connections limit and crashes my application.

What is yobuko, who let it into my database, and how can I stop it from killing my site?

With the lack of a better answer - I'll write a script that hunts these connections and kill them every couple of minutes.

I'm using hobby-dev database level that according to this article on heroku should work as long as I accept up to 4 hours downtime per month (that's ok for me)

EDIT: As I had the Yobuko connections, I also started having other connections called "puma: cluster worker XX."

The last sql they run is:

SELECT "oid", "typname" FROM "pg_type" WHERE (("typtype" = 'b') AND 
("typname" IN ('hstore')))

Here's a screen shot:

回答1:

I faced the same problem. Heroku got back to me with the tip to use select pg_terminate_backend(sub1.pid) from (select pid from pg_stat_activity where application_name = 'yobuko' and state = 'idle') as sub1; to kill the idle connections selectively. I’ll try to combine it with the scheduler plugin to run it automatically.

The reason is a malfunction of a monitoring tool they’re using for hobby tier databases (maybe implying that the standard tier and above are not affected). They’re working on a fix but don’t have a timeline yet.

回答2:

It seems there was a problem with Heroku from 5/9/2018 to 13/9/2018 with their eu hobby dev databases. Their internal tools had a connection leak that opened connections with appname yobuku and with another appname called puma cluster worker.

The only out was to manually kill these connections every few hours.

The problem seems to be resolved now.