IBM Cloud Docs
接続の管理

接続の管理

Databases for PostgreSQL デプロイメントへの接続ではリソースが使用されるため、デプロイメントのパフォーマンスを調整するために必要な接続数を考慮することが重要です。 PostgreSQL は、ランナウェイ接続の動作によってデプロイメントのリソースが大量に消費されないように、max_connections 設定を使用して、接続の数 (および接続によって消費されるリソース) を制限します。

max_connections の値は、管理者ユーザーpsql を使用して確認できます。

ibmclouddb=> SHOW max_connections;
 max_connections
-----------------
 115
(1 row)

接続制限

Databases for PostgreSQL は、プロビジョン時に PostgreSQL データベースへの接続の最大数を 115 に設定します。スーパーユーザーがデータベースの状態と完全性を維持するために 15 個の接続が予約され、ユーザーとアプリケーションは 100 個の接続を使用できます。 データベースへの接続数が 100 接続制限を超えると、新規接続は失敗し、エラーが返されます。

FATAL: remaining connection slots are reserved for
non-replication superuser connections

デプロイメントの接続制限を超えると、アプリケーションがデータベースに到達できなくなる可能性があります。

管理者ユーザー、psql、および pg_stat_database を使用して、デプロイメントへの接続数を確認できます。

SELECT count(distinct(numbackends)) FROM pg_stat_database;

接続先を調べる必要がある場合は、接続数のデータベース別の内訳を表示することができます。

SELECT datname, numbackends FROM pg_stat_database;

特定のデータベースへの接続をさらに調査するには、pg_stat_activity に照会を実行します。

SELECT * FROM pg_stat_activity WHERE datname='ibmclouddb';

接続の終了

管理者ユーザーには、pg_signal_backend 役割が付与されています。 リセットまたはクローズする必要がある接続が見つかった場合、管理ユーザーは pg_cancel_backendpg_terminate_backendの両方を使用できます。 プロセスの pid は、pg_stat_activity 表で確認できます。

  • pg_cancel_backend は、接続を終了せずに、実行中の他の照会を停止することなく、接続の現在の照会を取り消します。
    SELECT pg_cancel_backend(pid);
    
  • pg_terminate_backend は、プロセス全体を停止し、接続をクローズします。
    SELECT pg_terminate_backend(pid);
    

管理者ユーザーは、デプロイメントのスーパーユーザー以外のすべてのユーザーの接続をリセットまたはクローズできます。 ibm-replication ユーザーからのレプリケーション接続を終了しないように注意してください。終了すると、デプロイメントの高可用性が損なわれることになります。

接続の終了

デプロイメントが接続制限に達した場合、またはデプロイメントへの接続に問題があり、接続数が多すぎることが疑われる場合は、デプロイメントへのすべての接続を切断してください。

UI の_「設定」_タブには、デプロイメントに対する End Connections ボタンがあります。 デプロイメントに接続されているあらゆるものが切断されるので、慎重に使用してください。

デプロイメントへの接続を終了するための CLI コマンドは以下のとおりです。

ibmcloud cdb deployment-kill-connections <deployment name or CRN>

Cloud Databases API でも、すべての接続を終了する操作を実行できます。

接続プーリング

接続制限の超過を防ぎ、アプリケーションからの接続を効率的に処理するための 1 つの方法として、接続プーリングを使用する方法があります。 IBM Cloud® Databases for PostgreSQL の接続制限を 500 を超える接続に設定することが必要になった場合は、接続プーリングを使用するか、接続をより効率的に使用および維持する方法を見直すことを検討してください。 PostgreSQL コミュニティーのパフォーマンス・ベンチマーキングでは、最適なデータベース・パフォーマンスのために、接続数を 500 以下にすることを推奨しています。

多くの PostgreSQL ドライバーのライブラリーに、接続プーリングのクラスや機能が含まれています。 ドライバーの資料を参照して、ユースケースに最適な接続プーリングを実装する必要があります。 例えば、 Python ドライバー Psycopg2 には、アプリケーションで接続プーリングを処理するための クラスがあります。 Java PostgreSQL JDBC ドライバーには、 アプリケーション・レベルとアプリケーション・サーバー・レベルの両方で接続プールを行うためのメソッドがあります。

あるいは、 PgBouncer などのサード・パーティー・ツールを使用して、アプリケーションの接続を管理することもできます。

接続制限の引き上げ

PostgreSQL は、接続ごとに一定量のメモリーを割り振ります。通常、接続ごとに 5 MB から 10 MB が割り振られます。 接続制限を引き上げる前に、デプロイメントで使用可能な合計メモリー量を考慮することが重要です。 接続制限を引き上げるには、まず、より多くの接続に対応できるだけの十分なメモリーを確保するために、デプロイメントをスケーリングする必要がある場合があります。

次に、デプロイメントの max_connections の値を変更します。 PostgreSQL 構成に永続的な変更を行うには、Cloud Databases CLI プラグインまたは API を使用して、デプロイメントの構成ファイルに変更を書き込みます。

例えば、max_connections を 215 に引き上げるには、デプロイメントをデータ・メンバーごとに少なくとも 2 GB の RAM (デプロイメントの合計の RAM は 4 GB) にスケーリングすることをお勧めします。 スケーリング操作が終了したら、接続制限を設定します。 max_connections を調整する前に、以下のようなコマンドを使用して、優先領域をターゲットにしてください。

ibmcloud target -r <region>

次に、以下のようなコマンドを使用して、デプロイメント・グループで使用可能なメモリー量を増やします。

ibmcloud cdb deployment-groups-set example-deployment member --memory 4096

最後に、次のようなコマンドを使用して max_connections を調整します。

ibmcloud cdb deployment-configuration example-deployment '{"configuration":{"max_connections":215}}'

API を使用して変更を行うには、次のようにします。

curl -X PATCH `https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"memory": {
        "allocation_mb": 4096
      }
    }'

curl -X PATCH 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/configuration' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"configuration":{
        "max_connections":215
      }
    }'

接続制限および TCP/IP キープアライブ設定

ネットワーク接続またはフェイルオーバーが発生した場合、TCP キープアライブ・タイムアウトに達するまで、切断された TCP/IP 接続がハーフ・オープン/クローズ状態のままになる可能性があります。 このシナリオを回避するには、特定のアプリケーション・ドライバーでsocket_timeoutconnection_timeoutの設定も行います。 適切な設定は、特定のワークロードに基づいて変化するため、実動に移行する前にロード・テストを実行することが重要ですconnection_timeout の適切な開始点は 2 秒から 5 秒です。 socket_timeout の場合、開始点として 30 秒から 60 秒を使用することをお勧めします。

さらに、サーバー・サイドでは、以下のキープアライブ構成がデフォルトとして使用されます。

  • tcp_keepalives_idle は 5 分に設定されています。
  • tcp_keepalives_interval プローブ間隔は 10 秒に設定されています。
  • tcp_keepalives_count は 6 に設定されています。

ハーフオープン/クローズされた接続または接続試行のバーストによってデプロイメントが圧倒されないようにするには、 Postgres の max_connections パラメーター を、予期される接続数の少なくとも 2 倍に設定します。

接続制限に達した場合は、即時にすべての接続を終了させることができます。