Je développe une application sur Heroku avec un backend Postgresql. Périodiquement, je reçois ce message d'erreur lorsque j'essaie d'accéder à la base de données, à la fois à partir du CLI et du chargement d'une page sur le serveur :
psql: FATAL: remaining connection slots are reserved for non-replication superuser connectionsQuelqu'un a-t-il déjà vu cela ou peut-il m'indiquer la bonne direction ?
Vous devez soit augmenter le max_connections ou (probablement mieux) utiliser la mise en commun des connexions pour acheminer un grand nombre de demandes d'utilisateurs à travers un pool de connexions plus petit.
https://wiki.postgresql.org/wiki/Number_Of_Database_Connections
Un autre problème courant est celui d'une application côté client qui se plante et laisse des connexions ouvertes, puis en ouvre de nouvelles au redémarrage. Si ce genre de chose se produit souvent, vous finirez par manquer de connexions. Ou l'application est simplement mal configurée et ouvre trop de connexions.
Je ne pense pas pouvoir modifier les paramètres de configuration sur Heroku. Existe-t-il un moyen de fermer toutes les connexions ouvertes ?
Avec un peu de chance, le serveur est configuré pour les paquets keepalive de manière assez agressive. Cela permettra aux sessions de se terminer dans un délai raisonnable si les connexions sont brusquement interrompues. Si cela n'est pas configuré, si vous pouvez vous connecter en tant que super-utilisateur de la base de données, vous pouvez identifier l'adresse du serveur. pid pour les sessions et utiliser l'option pg_terminate_backend() pour les tuer. Pour éviter ce problème, veillez à fermer correctement les connexions plutôt que de tuer brutalement le côté client.
Heroku a parfois un problème avec l'équilibrage de la charge de la base de données.
André Laszlo , markshiz et moi avons tous signalé avoir traité ce sujet dans les commentaires sur la question.
Pour vous épargner un appel au support, voici la réponse que j'ai obtenue du support Heroku pour un problème similaire :
Bonjour,
L'une des limites des bases de données de niveau amateur est la maintenance inopinée. De nombreuses bases de données pour amateurs fonctionnent sur un seul serveur partagé, et nous devons parfois redémarrer ce serveur pour des raisons de maintenance matérielle, ou migrer les bases de données vers un autre serveur pour équilibrer la charge. Lorsque cela se produit, vous verrez une erreur dans vos journaux ou aurez des problèmes de connexion. Si le serveur redémarre, la remise en ligne de la base de données peut prendre 15 minutes ou plus.
La plupart des applications qui gèrent un pool de connexion (comme ActiveRecord dans Rails) peuvent simplement ouvrir une nouvelle connexion à la base de données. Cependant, dans certains cas, une application ne sera pas en mesure de se reconnecter. Si cela se produit, vous pouvez redémarrer votre application pour la remettre en ligne.
C'est l'une des raisons pour lesquelles nous vous déconseillons d'utiliser des bases de données amateurs pour les applications de production critiques. Les bases de données Standard et Premium incluent des notifications pour les événements d'arrêt, et sont beaucoup plus performantes et stables en général. Vous pouvez utiliser pg:copy pour migrer vers un plan standard ou premium.
Si cela continue, vous pouvez essayer de provisionner une nouvelle base de données (sur un serveur différent) avec heroku addons:add, puis utiliser pg:copy pour déplacer les données. Gardez à l'esprit que les règles des niveaux de loisirs s'appliquent au plan de base à 9 $ ainsi qu'à la base de données gratuite.
Merci, Bradley
Je me demande quelle est la réponse standard lorsque vous êtes sur un plan de base de données de 50 $ par mois ?
Seuls les niveaux de loisirs utilisent des serveurs de base de données partagés. Avec le plan de 50 $ par mois, vous avez votre propre serveur, donc si vous rencontrez ce problème, c'est votre propre application qui le crée. Vous disposez de plus d'options d'administration avec le plan de 50 $/mois, il est donc plus facile de diagnostiquer et de réparer.
J'ai essayé d'implémenter la mise en commun des connexions du côté de Django en utilisant :
https://github.com/gmcguire/django-db-pool
mais j'ai toujours reçu cette erreur, bien que j'aie réduit le nombre de connexions disponibles en dessous du quota standard de 20 connexions ouvertes dans la base de données de développement.
Il y a un article ici sur la façon de déplacer votre base de données postgresql vers le niveau gratuit/privé d'Amazon RDS. Cela vous permettrait de définir max_connections plus élevé. Cela vous permettra également de regrouper les connexions au niveau de la base de données en utilisant PGBouncer.
https://www.lewagon.com/blog/how-to-migrate-heroku-postgres-database-to-amazon-rds
UPDATE :
Heroku a répondu à mon ticket ouvert et a déclaré que ma base de données était mal équilibrée en termes de charge dans leur réseau. Ils ont dit que les améliorations apportées à leur système devraient empêcher des problèmes similaires à l'avenir. Néanmoins, le support a déplacé manuellement ma base de données et les performances se sont nettement améliorées.
Pour reproduire le même problème sous Linux :
for i in {1..300}; do
PGPASSWORD=MY_PASSWORD gnome-terminal -e $'/usr/bin/psql -h \'127.0.0.1\' -p 5432 -U MY_USERNAME'
doneDans un client dotnet, vous pouvez lire :
System.InvalidOperationException: An exception has been raised that is likely due to a transient failure. ---> Npgsql.PostgresException (0x80004005): 53300: sorry, too many clients already
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
J'ai le même problème. J'ai lu quelque part que le support Heroku avait "détecté quelques problèmes" sur certains serveurs, et ils ont recommandé à l'utilisateur en question de provisionner une nouvelle base de données Basic et de migrer vers celle-ci en utilisant pgbackups. Mon problème maintenant est que l'application est si nouvelle que je n'ai pas encore créé de sauvegarde, et je reçois la même erreur en essayant d'en créer une bien sûr :D
0 votes
Pour mémoire, j'ai pu utiliser
heroku pgbackupspour créer une sauvegarde malgré cette erreur.0 votes
Pour reproduire ce problème, vous pouvez créer un grand nombre de terminaux.
.batscript dans Windows pour cela :for /l %%x in (1, 1, 100) do ( start psql )où 100 est le nombre souhaité de backends.0 votes
J'ai eu le même problème. Je n'ai pas réussi à transférer les données vers une nouvelle base de données en utilisant
pg:backups copy,pg:backups captureen s'y connectant à partir depgAdminsur mon propre ordinateur, ou de toute autre manière que je pourrais imaginer. Mêmepg:killalln'a pas aidé. Une heure plus tard, j'ai réessayé et les connexions étaient à 50-50, donc après quelques tentatives, j'ai eu un succèspg:backups copyet mon application est de retour dans les airs. Ce n'était... pas une journée amusante. Si tu as googlé ça, bois un verre d'eau.1 votes
J'ai à nouveau ce problème. Quelle chance d'avoir documenté mon expérience précédente... Edit : cette fois le redémarrage a suffi.
0 votes
J'ai eu cette erreur lors de la mise à jour de gitlab. Redémarrer gitlab et réessayer l'installation a résolu le problème.
0 votes
Je reproduis l'erreur en créant au moins 100 demandes de connexion à Postgres. Je vais essayer d'augmenter les limites de connexions maximales