IBM Cloud Docs
Databases for PostgreSQL 設定の変更

Databases for PostgreSQL 設定の変更

IBM Cloud® Databases for PostgreSQL PostgreSQL の設定の一部を変更できるようにし、 PostgreSQL データベースをユースケースに合わせて調整できるようにします。 データベース構成への永続的な変更を行うには、 Cloud Databases CLI プラグイン または API を使用して、デプロイメントの構成ファイルに変更を書き込みます。

構成はスキーマで定義されています。 変更を加えるには、対象の設定と新しい設定値を含む JSON オブジェクトを API または CLI に渡します。 例えば、設定 max_connections を150に設定するには、以下のように指定します：

{"configuration":{"max_connections":150}}

CLI または API へ。

詳細は 接続の管理 を参照してください。

Databases for PostgreSQL での CLI の使用

deployment-configuration-schema コマンドを使用して、デプロイメントのデフォルト構成を確認できます。 コマンド deployment-configuration-schema の出力は、設定を変更した後でもデフォルト設定のみを表示します。 データベース固有の変更を確認するには、データベースを直接クエリしてください。

ibmcloud cdb deployment-configuration-schema <INSTANCE_NAME_OR_CRN>

同様に、 deployment-configuration コマンドを使用して構成を変更します。

ibmcloud cdb deployment-configuration <INSTANCE_NAME_OR_CRN> [@JSON_FILE | JSON_STRING]

このコマンドは、変更内容を JSON オブジェクトまたはファイルから読み取ります。 詳しくは、リファレンス・ページを参照してください。

IBM Cloud® Databases for PostgreSQL での API の使用

2 つのデプロイメント構成エンドポイントにより、構成スキーマの表示と構成の変更が可能になります。 構成スキーマを表示するには、GET 要求を /deployments/{id}/configuration/schema に送信します。

構成を変更するには、変更する設定を JSON オブジェクトとして PATCH 要求の本文に指定して /deployments/{id}/configuration に送信します。

詳細については、 APIリファレンスを参照してください。

利用可能なIBM Cloud® Databases for PostgreSQL構成設定

このセクションでは、利用可能な IBM Cloud Databases for PostgreSQL の設定に関する情報を提供します。 ここに記載されていない設定を製品機能の改善案として提案する場合は、 IBM アイデアポータル でアイデアを提出してください。 ご希望であれば、 IBM Cloud Ideas で、 IBM Cloud の機能強化のみを表示するように制限できます。

IBM Cloud® Databases for PostgreSQL タイムゾーンの設定

IBM Cloud® Databases for PostgreSQL デプロイメントのタイム・ゾーンは、常に UTC (協定世界時) です。 この設定は、クライアントによって構成することはできません。

IBM Cloud® Databases for PostgreSQL メモリ設定

shared_buffers

  • デフォルト - 32000 (8 KiB バッファーの数、または約 262 MB)
  • 推奨される最大値: 使用可能な RAM の 25%
  • データベースを再始動する - はい

shared_buffers のメモリー割り振り量は、デプロイメントの RAM の 25% にすることをお勧めします。 設定値を shared_buffers これ以上高くすると、メモリ問題が発生してデータベースがクラッシュする可能性があり、またデータは既にOSによってバッファリングされている可能性が高いため、データベースのパフォーマンスが低下する恐れがあります。 割り当てられたメモリ量と同等、ほぼ同等、またはそれ以上に設定 shared_buffers すると、データベースの起動が妨げられます。 設定では、8 KiB の共有メモリー・バッファーの数が指定されます。

例えば、1 GB の shared_buffers スペースは 1048576 KiB であるため、(1048576 KiB / 8 KiB) により 131072 個のバッファーとなります。 デプロイメントは、shared_buffers に割り振らなくても追加の RAM をキャッシングとパフォーマンスのために使用することができます。 割り当てられた RAM をすべて使用するようにデータベースを構成しなくても、デプロイメントはすべての RAM を使用できます。

既存のワークロードの場合、または RAM をスケーリングしているときには、メモリーを共有バッファーにまで拡大することが最適な操作とはならない可能性があります。 代わりに、テーブルと索引のキャッシュ・ヒット率を追跡してください。 キャッシュヒット率が90％台後半である場合、OSが他の領域のメモリを使用できるようにし、 shared_buffers 増大させないようにする。

admin ユーザーや pg_monitor 役割を持つユーザーは、以下の照会を使用してキャッシュ・ヒット率を追跡できます。

テーブル

SELECT
  sum(heap_blks_read) as heap_read,
  sum(heap_blks_hit)  as heap_hit,
  sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as table_hit_ratio
FROM
  pg_statio_user_tables;

索引

SELECT
  sum(idx_blks_read) as idx_read,
  sum(idx_blks_hit)  as idx_hit,
  (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as index_hit_ratio
FROM
pg_statio_user_indexes;

work_mem 値は、 shared_buffer 構成値および max_connection 構成値に関連して自動的に調整されます。

IBM Cloud® Databases for PostgreSQL一般設定

max_connections

max_locks_per_transaction

  • デフォルト-64
  • オプション - 最小値は10
  • データベースを再始動する - はい

max_prepared_transactions

synchronous_commit

  • デフォルト- local
  • データベースを再始動する - いいえ
  • オプション - local、on、またはoff
  • 注 - synchronous_commitをオフに設定すると、トランザクション・コミット率が増加しますが、クリーンでないシャットダウンが発生した場合は、コミットされたトランザクションが失われます。 synchronous_commitがonに設定されている場合、トランザクションは、リーダーと少なくとも 1 つのレプリカに書き込まれたときにのみコミットされます。 したがって、on設定は、少なくとも 3 つのメンバーに水平方向にスケーリングされたフォーメーションでのみ使用できます。 この変更を実施する前に、 高可用性を 参照してください。

effective_io_concurrency

  • デフォルト- 12
  • データベースを再始動する - いいえ
  • 注意事項 - この設定はデフォルトのままにしておくことをお勧めします。 プロファイルが作成された SQL 照会があり、非効率なビットマップ・ヒープ・スキャンが確認された場合にのみ、この値を大きくしてください。 IOPSはディスクサイズに依存 するため、デフォルトまたはそれより小さいサイズのディスクでこの設定値を上げることも推奨されません。

deadlock_timeout

  • デフォルト- 10000
  • データベースを再始動する - いいえ
  • オプション - 最小値 100
  • 注意事項 - デッドロックを検査するまで待機するミリ秒数であり、ロック待機がログに記録される間隔でもあります。 ロギング統合を介して使用可能なログ。 この数値の設定が小さすぎると、パフォーマンスに悪影響があります。

log_connections

  • デフォルト- off
  • データベースを再始動する - いいえ
  • オプション - on 値または off 値
  • 注記 - この値を に設定すると、 on ログが詳細になります。 また、60 秒ごとにメトリックが抽出されるので、モニタリング・ツールの接続も示されます。 これを on に設定する場合は、接続 URI に application_name を設定してログに概要を保持するようにすることをお勧めします。示される IP アドレスは Kubernetes 内部 IP だからです。 接続URIの調整に関する詳細は 、 PostgreSQL のドキュメントに記載されています。 off に設定した場合は、デフォルト設定と比べて動作の変化はなく、接続はログに記録されません。 ログは、ロギングとの統合を行うと利用できるようになります。 on に設定した場合は、次の例のような行がログで示されます。この例では、アプリケーション名は test-app に設定されています。
2021-03-01 10:27:56 UTC [[unknown]] [00000] [708]: [2-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  connection authorized: user=admin database=ibmclouddb application_name=test-app SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, compression=off)

log_disconnections

  • デフォルト- off
  • データベースを再始動する - いいえ
  • オプション - on 値または off 値
  • 注記 - この値を に設定すると、 on ログが詳細になります。 また、監視ツールが60秒ごとにメトリクスを抽出する際の切断も表示します。 これを on に設定する場合は、接続 URI に application_name を設定してログに概要を保持するようにすることをお勧めします。示される IP アドレスは Kubernetes 内部 IP だからです。 接続URIの調整に関する詳細は 、 PostgreSQL のドキュメントに記載されています。 off に設定した場合は、デフォルト設定と比べて動作の変化はなく、切断はログに記録されません。 ログは、ロギングとの統合を行うと利用できるようになります。 on に設定した場合は、次の例のような行がログで示されます。この例では、アプリケーション名は test-app に設定されています。
2021-03-01 10:27:56 UTC [test-app] [00000] [708]: [3-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  disconnection: session time: 0:00:00.793 user=admin database=ibmclouddb host=127.0.0.1 port=50638

log_min_duration_statement

  • デフォルト- 100
  • データベースを再始動する - いいえ
  • オプション - 最小値 100
  • 注意事項 - 指定したミリ秒数より長くかかっているステートメントがログに記録されます。

tcp_keepalives_idle

  • デフォルト- 111
  • データベースを再始動する - いいえ

tcp_keepalives_interval

  • デフォルト- 15
  • データベースを再始動する - いいえ

tcp_keepalives_count

  • デフォルト- 6
  • データベースを再始動する - いいえ

IBM Cloud® Databases for PostgreSQL WAL設定

archive_timeout

  • デフォルト- 1800
  • データベースを再始動する - いいえ
  • オプション - 最小値 300
  • 注意事項 - 次の WAL ファイルへの切り替えを強制するまで待機する秒数。 この秒数が経過した場合、およびデータベース・アクティビティーがあった場合、サーバーは新規セグメントに切り替えます。 データがアーカイブされない状態でいる時間を効果的に制限できます。

次の 3 つの設定 wal_level、max_replication_slots、および max_wal_senders によって、wal2json 論理デコード・プラグインを使用できるようになります。 このプラグインを使用しない場合は、これらの設定をデフォルトのままにします。

wal_level

  • デフォルト- replica
  • データベース再始動 - 必要
  • 注意事項 - WAL レベルを制御します。 許可される値は または replica です logical。 論理デコードを使用 logical するように設定します。 論理デコードを使用しない場合に logical を使用すると WAL サイズが大きくなります。これには欠点がいくつかあるだけで、利点は一切ありません。

max_replication_slots

  • デフォルト- 10
  • データベース再始動 - 必要
  • 注意事項 - 同時に定義できるレプリケーション・スロットの最大数。 デフォルトおよび最小のスロット数は 10 です。 高可用性 (HA) のためにデプロイメントが内部使用するものとして、20 個のスロットが予約されます。 スロットを使用するには、20 を超える値を設定し、コンシューマーごとに 1 つのスロットを用意する必要があります。 予期されるコンシューマーごとに、最小数を超えるスロットを 1 つ追加します。 wal2json を使用し、max_replication_slots を大きくしないと、HA および読み取り専用レプリカに影響が生じる可能性があります。 を使用 wal2json していない場合は、この設定をデフォルトのままにしておいてください。

max_wal_senders

  • デフォルト- 12
  • データベース再始動 - 必要
  • 注意事項 - 同時に実行できる WAL 送信側プロセスの最大数。 デフォルト値かつ最小値は12です。 コンシューマーごとに 1 つの wal_sender が必要です。 高可用性 (HA) のためにデプロイメントが内部使用するものとして、20 個のスロットが予約されます。 値は20以上に設定する必要があり、予想される消費者数ごとに最低値に加えて wal_sender さらに1つ追加することが推奨されます。 wal2json を使用し、max_wal_senders を大きくしないと、HA および読み取り専用レプリカに影響が生じる可能性があります。 を使用 wal2json していない場合は、この設定をデフォルトのままにしておいてください。