Le nombre de connexions pour les bases de données Google Cloud SQL PostgreSQL est relativement faible. Selon le plan, cela se situe entre 25 et 500, tandis que la limite pour MySQL dans Google Cloud SQL se situe entre 250 et 4000, atteignant 4000 très rapidement.
Nous avons actuellement un certain nombre d'instances d'essai pour différents clients fonctionnant sur Kubernetes et soutenues par le même serveur Google Cloud SQL Postgres. Chaque instance utilise un ensemble distinct de bases de données, de rôles et de connexions (un par service). Nous avons déjà atteint la limite de connexions pour notre plan (50) et nous ne sommes même pas près d'atteindre les limites de mémoire ou de processeur. Le regroupement de connexions ne semble pas être une option, car les connexions se font avec différents utilisateurs. Je me demande maintenant pourquoi la limite est si basse et s'il existe un moyen d'augmenter la limite sans avoir à passer à un plan plus cher.
Il y a une demande de fonctionnalité dans le Public Issue Tracker pour exposer et donc contrôler max_connections
dans PostgreSQL. Ce commentaire (je le reproduis ici) explique les raisons de définir le nombre de connexions tel qu'il est actuellement:
Per-tier max_connections is now fully rolled out. As shown on
https://cloud.google.com/sql/faq#sizeqps, the limits are now:
Memory size, in GiB | Maximum concurrent connections
--------------------+-------------------------------
0.6 (db-f1-micro) | 25
1.7 (db-g1-small) | 50
3.75 up to 6 | 100
6 up to 7.5 | 150
7.5 up to 15 | 200
15 up to 30 | 250
30 up to 60 | 300
60 up to 120 | 400
120 and above | 500
I understand your frustration about the micro/small instances having fewer than 100
concurrent connections and the lack of control of this flag. We arrived at these values by
taking the available RAM, reducing it by overhead, shared buffers, autovacuum memory and
then dividing the remaining ram by typical per-connection memory and rounding off. This
gives us the number of connections that can be used without risk of hitting out-of-memory
condition
The basic premise of a fully managed service with an attached SLA is that we provide safe
hosting. This is what motivates us using a max_connections that is safe against OOM.
Votre option est, comme vous avez supprimé le regroupement de connexions, d'utiliser une instance avec mémoire supérieure .
MISE À JOUR:
Comme mentionné dans n commentaire du fil mentionné, il y a eu des changements dans les paramètres de connexions max, qui sont maintenant:
De plus, les valeurs par défaut peuvent désormais être remplacées par des indicateurs , jusqu'à 260K connexions.