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％台後半なら、 shared_buffers を増やす代わりに、OSに他の分野のメモリを使わせよう。

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;

IBM Cloud® Databases for PostgreSQL一般設定

max_connections

• デフォルト - 115
• データベースを再始動する - はい
• 注意事項 - 最大接続数を増やす前にスケーリングしなければならない場合があります。

max_locks_per_transaction

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

max_prepared_transactions

• デフォルト- 0
• データベースを再始動する - はい
• 注意事項 - デフォルト値の 0 は、 プリペアド・トランザクションの使用を無効にする。

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以上に設定する必要があり、予想される消費者1人当たり、最小値より1つ多く wal_sender。 wal2json を使用し、max_wal_senders を大きくしないと、HA および読み取り専用レプリカに影響が生じる可能性があります。 wal2json を使用しない場合、この設定はデフォルトのままにしてください。