Как увеличить лимит подключений для базы данных Google Cloud SQL Postgres?

Question

Количество подключений к базам данных Google Cloud SQL PostgreSQL относительно невелико. В зависимости от плана это где-то между 25 и 500, в то время как предел для MySQL в Google Cloud SQL составляет от 250 до 4000, очень быстро достигая 4000.

В настоящее время у нас имеется несколько пробных экземпляров для разных клиентов, работающих в Kubernetes и поддерживаемых одним и тем же сервером Google Cloud SQL Postgres. Каждый экземпляр использует отдельный набор базы данных, ролей и соединений (по одному на службу). Мы уже достигли предела числа подключений для нашего плана (50), и мы даже близко не подошли к пределам памяти или процессора. Пул соединений, кажется, не вариант, потому что соединения с разными пользователями. Теперь мне интересно, почему лимит такой низкий и есть ли способ увеличить лимит без необходимости переходить на более дорогой план.

Answer 1

Похоже, Google только что выпустил это как бета-функцию. При создании или редактировании экземпляра базы данных вы можете добавить флаг с именем max_connections, где вы можете ввести новый лимит между 14 и 262143 соединениями.

Answer 2

В модуле отслеживания общедоступных проблем имеется запрос на возможность выставления и, следовательно, управления max_connections в PostgreSQL. Этот комментарий (я его здесь воспроизвожу) объясняет причины установки количества соединений, как сейчас:

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.

Вы можете, так как вы отказались от пула соединений, использовать экземпляр с памятью выше .

UPDATE:

Как упомянуто в комментарии упомянутой темы, были внесены изменения в настройки макс. Соединений, которые теперь:

Кроме того, значения по умолчанию теперь могут быть переопределены с флагами , до 260K соединений.