Google Cloud SQL PostgreSQLデータベースの接続数は比較的少ないです。計画にもよりますが、これは25〜500の範囲にありますが、Google Cloud SQLのMySQLの制限は250〜4000であり、非常に迅速に4000に達します。
現在、Kubernetesで実行され、同じGoogle Cloud SQL Postgresサーバーでサポートされているさまざまな顧客向けの多数のトライアルインスタンスがあります。各インスタンスは、データベース、ロール、および接続の個別のセット(サービスごとに1つ)を使用します。計画の接続の制限(50)に既に到達しており、メモリまたはCPUの制限に近づいていません。接続は異なるユーザーとの接続であるため、接続プーリングはオプションではないようです。私は今、なぜ制限がそんなに低いのか、より高価なプランにアップグレードすることなく制限を増やす方法があるのかと思っています。
Public Issue Tracker には、公開して制御するための機能リクエストがあります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.
接続プーリングを破棄したので、オプションは higher memory でインスタンスを使用します。
UPDATE:
前述のスレッドの コメント で説明したように、最大接続設定に変更が加えられました。現在は次のとおりです。
さらに、デフォルトは フラグで上書き 、最大260K接続になりました。