Amazon RDS for PostgreSQL での高いオブジェクト数の管理

autovacuum は、作業量と比較してワーカーが不足しているため、トランザクション ID の増加やテーブルの肥大化に対応しきれない可能性があります。

推奨されるアクション: autovacuum をチューニングして、特定の数のテーブルと特定のワークロードに適切に対応させるには、いくつかの要素を考慮する必要があります。適切な autovacuum 設定を決定する方法については、「PostgreSQL autovacuum を使用するためのベストプラクティス」を参照してください。postgres_get_av_diag ユーティリティを使用して、トランザクション ID の増加に関する問題をモニタリングします。

Amazon RDS は、pg_upgrade の実行中に「--link」オプションを使用して、データファイルのコピーを作成する必要がないようにしますが、スキーマメタデータは新しいバージョンのデータベースに復元する必要があります。並列 pg_restore を使用しても、リレーションの数が多いとダウンタイムが増加します。

カタログサイズによる一般的なパフォーマンスの低下。各テーブルとそれに関連する列は、pg_attribute、pg_class、および通常のデータベースオペレーションで頻繁に使用される pg_depend テーブルに追加されます。特定の待機イベントは表示されませんが、共有バッファの効率に影響します。

推奨されるアクション: これらの特定のテーブルに対してテーブルの肥大化を定期的にチェックし、必要に応じてこれらの特定のテーブルに VACUUM FULL を実行します。カタログテーブルの VACUUM FULL では ACCESS EXCLUSIVE ロックが必要です。これは、オペレーションが完了するまで他のクエリがそれらにアクセスできないことを意味します。

エラー: 「ファイル記述子不足: システムで開いているファイルが多すぎます。ファイルを解放して再試行してください」。PostgreSQL のパラメータ max_files_per_process は、各プロセスが開くことができるファイルの数を決定します。多数のテーブルを結合する接続の数が多い場合、この制限に達する可能性があります。

推奨されるアクション:

エラー: 「デバイスに空き容量がありません」。ストレージの空き領域が大量にある場合にこれが観察された場合は、inode が不足していることが原因です。Amazon RDS 拡張モニタリングは、使用中の inode とホストで使用できる最大数を可視化します。

一時テーブルは autovacuum によってバキューム処理されませんが、存在中はトランザクション ID を保持し、削除しないと循環が発生する可能性があります。

推奨されるアクション: 一時テーブルは、それらを作成したセッション期間中存続するか、手動で削除できます。ベストプラクティスとして、一時テーブルを使用する際に長時間実行されるトランザクションを避けることで、これらのテーブルが使用済みトランザクション ID の最大値の増加に寄与するのを防ぐことができます。

カタログサイズによる一般的なパフォーマンスの低下。セッションが継続的に一時テーブルを作成および削除すると、通常のデータベースオペレーションで頻繁に使用される pg_attribute、pg_class、pg_depend テーブルにテーブルが追加されます。特定の待機イベントは表示されませんが、共有バッファの効率に影響します。

推奨されるアクション:

論理レプリケーションでは WAL を利用して変更をキャプチャおよび転送するため、ログに記録されないテーブルは通常、ブルー/グリーンデプロイを含む論理レプリケーションに含まれません。

フェイルオーバーによるマルチ AZ 再起動、Amazon RDS ポイントインタイムリカバリ、Amazon RDS メジャーバージョンアップグレードなどのデータベースのクラッシュ回復を含むデータベース状態においては、ログに記録されないテーブルを切り捨てるシリアル化されたオペレーションが発生します。これにより、予想よりもはるかに高いダウンタイムが発生する可能性があります。

推奨されるアクション:

場合によっては、計画時間のオーバーヘッドが増加し、クエリの実行計画がより複雑になり、チューニングの機会を特定することが難しくなる場合があります。18 より前の PostgreSQL バージョンでは、ワークロードの高いパーティションが多いと、LWLock:LockManager 待機につながる可能性があります。

推奨されるアクション: データの整理を完了させると同時に、クエリの実行パフォーマンスも向上させるために必要な最小限のパーティション数を決定します。

パーティションの数が非常に多いと、事前作成や削除などのメンテナンスの問題が発生します。autovacuum はパーティションを通常のリレーションとして扱い、定期的なクリーンアップを実行する必要があるため、タスクを完了するのに十分なワーカーが必要です。

推奨されるアクション:

エラー: 「ファイル記述子不足: システムで開いているファイルが多すぎます。ファイルを解放して再試行してください」。PostgreSQL のパラメータ max_files_per_process は、各プロセスが開くことができるファイルの数を決定します。多数のテーブルを結合する接続の数が多い場合、この制限に達する可能性があります。

推奨されるアクション:

エラー: 「デバイスに空き容量がありません」。ストレージの空き領域が大量にある場合にこれが観察された場合は、inode が不足していることが原因です。Amazon RDS 拡張モニタリングは、使用中の inode とホストで使用できる最大数を可視化します。

任意のタイプの設定変更またはアップグレードに、Amazon RDS ブルー/グリーンデプロイを使用する予定がある場合は、多数のシーケンスがスイッチオーバーに与える影響を理解することが重要です。スイッチオーバーの最後のフェーズの 1 つとして、シーケンスの現在の値を同期させる処理が行われますが、その数が数千に及ぶ場合、スイッチオーバー全体の所要時間が長くなります。

推奨されるアクション: データベースワークロードがテーブルごとのシーケンスアプローチではなく共有 UUID の使用を許可する場合、スイッチオーバー中に同期ステップを削減できます。

現在、PostgreSQL では論理レプリケーション時にラージオブジェクトはレプリケートされません。詳細については、PostgreSQL のドキュメントの制約事項ページを参照してください。ブルー/グリーン設定では、ブルー環境内のラージオブジェクトはグリーン環境にレプリケートされません。

数百万のラージオブジェクトがあり、アップグレード中にインスタンスがそれらを処理できない場合、アップグレードはメモリ不足になり、失敗する可能性があります。PostgreSQL メジャーバージョンのアップグレードプロセスは、大きく分けて 2 つのフェーズで構成されます。pg_dump によるスキーマダンプと、pg_restore による復元です。データベースに数百万のラージオブジェクトがある場合は、アップグレード中に pg_dump と pg_restore を処理するために十分なメモリがインスタンスにあることを確認し、より大きなインスタンスタイプにスケールする必要があります。