接続の管理

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 といったサードパーティ製ツールを使用して、アプリケーションの接続を管理することもできます。 Databases for PostgreSQL のデプロイメントには、 PgBouncer's auth_query による認証機能が組み込まれているため、実行している PgBouncer インスタンスは、ローカルのパスワードリストを維持することなくデータベースに対してユーザーの認証を行うことができ、パスワードの変更も PgBouncer を再起動することなく反映されます。 設定手順については、「 PgBouncer を使用した接続プーリング 」を参照してください。

接続制限の引き上げ

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

次に、デプロイメントの 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/IP の接続が切断された後も、 TCP のキープアライブタイムアウトが切れるまで、その接続が「半開状態」または「半閉状態」のまま残る可能性があります。 このシナリオを回避するには、特定のアプリケーション・ドライバーで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倍に設定してください。

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