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_backend と 'pg_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は接続毎にある程度の量のメモリを割り当てます。 接続制限を引き上げる前に、デプロイメントで使用可能な合計メモリー量を考慮することが重要です。 接続制限を引き上げるには、まず、より多くの接続に対応できるだけの十分なメモリーを確保するために、デプロイメントをスケーリングする必要がある場合があります。

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

例えば、max_connections を 215 に引き上げるには、デプロイメントをデータ・メンバーごとに少なくとも 2 GB の RAM (デプロイメントの合計の RAM は 4 GB) にスケーリングすることをお勧めします。 スケーリング操作が終了したら、接続制限を設定します。

  1. max_connections を調整する前に、以下のようなコマンドで希望の地域をターゲットにしてください:
ibmcloud target -r <REGION>
  1. 次に、以下のようなコマンドを使用して、デプロイメント・グループで使用可能なメモリー量を増やします。
ibmcloud cdb deployment-groups-set deployment-example member --memory 4096
  1. 最後に、次のようなコマンドを使用して max_connections を調整します。
ibmcloud cdb deployment-configuration <DEPLOYMENT_NAME_OR_CRN> '{"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倍に設定してください。

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