スキップしてコンテンツを表示

Amazon RDS for PostgreSQL または Aurora PostgreSQL 互換での、LWLock:pg_stat_statements イベントに起因する問題を解決する方法を教えてください。

所要時間1分
0

Amazon Relational Database Service (Amazon RDS) または Amazon Aurora PostgreSQL 互換エディションにおいて、LWLock:pg_stat_statements 待機イベントに起因するパフォーマンスの問題を解決したいです。

解決策

pg_stat_statements モジュールは、SQL ステートメントに関する統計情報を追跡します。PostgreSQL 11 以降と互換性のある PostgreSQL DB インスタンスでは、pg_stat_statementsデフォルトでロードされます。詳細については、PostgreSQL のウェブサイトで pg_stat_statements を参照してください。

追跡される一意のステートメントの数が pg_stat_statements.max 値を超えると、PostgreSQL は実行頻度の低いクエリに関する統計情報を、共有メモリ内のハッシュテーブルから割り当て解除します。割り当てが解除されると、新しいエントリ用の領域が用意されます。

割り当ての解除中、PostgreSQL はハッシュテーブルに LWLock を使用して同時アクセスを防ぎます。これが原因で、同時実行のバックエンドプロセスがブロックされ、Performance Insights には待機イベント LWLock:pg_stat_statements が表示される場合があります。

注: ハッシュテーブルによりエントリが頻繁に割り当てられる場合、ワークロードの全体的なパフォーマンスが低下する可能性があります。

pg_stat_statements.max モジュールを増やす

LWLock:pg_stat_statements 待機イベントを低減するには、パラメータグループで pg_stat_statements.max 値を増やします。詳細については、PostgreSQL のウェブサイトで pg_stat_statements.max を参照してください。

注: pg_stat_statements.max 値を増やすと、ハッシュテーブルは追加の共有メモリを使用し、追加の SQL ステートメント情報を格納するようになります。

Amazon RDS for PostgreSQL では、DB パラメータグループで pg_stat_statements.max を変更します。

Aurora PostgreSQL 互換では、DB クラスターのパラメータグループまたは DB パラメータグループで値を変更します。

パラメータグループで pg_stat_statements.max を変更した後、DB インスタンスを再起動すると変更が反映されます。再起動中に、短時間の停止が発生する可能性があります。詳細については、「DB インスタンスの再起動: 基本手順」および「Aurora クラスター内の DB インスタンスを再起動する」を参照してください。

デフォルトの DB パラメータグループまたはデフォルトの DB クラスターパラメータグループ内のパラメータは、変更できません。デフォルトグループのパラメータを変更するには、カスタム DB パラメータグループまたはカスタム DB クラスターパラメータグループを作成してから、DB インスタンスまたは DB クラスターに関連付けてください。

注: 長いクエリテキストは、別ディスクのファイルに保存できます。長いクエリを使用したり、pg_stat_statements.max の値を増やしたりしたことが原因でファイルが肥大した場合、すべてのクエリテキストは破棄される場合があります。その場合、pg_stat_statements.query フィールドは空白になる可能性があります。詳細については、PostgreSQL のウェブサイトで「pg_stat_statements -- SQL の計画と実行に関する統計情報を追跡する」を参照してください。

pg_stat_statements エントリの数を削減する

PostgreSQL バージョン 17 を使用し、pg_stat_statements エントリの数を削減することをおすすめします。たとえば、PostgreSQL バージョン 17 以降を使用すると、定数の SAVEPOINT 名をプレースホルダーに置き換えられます。たとえば、以前のバージョンの PostgreSQL では、SAVEPOINT sp1SAVEPOINT sp2 は、2 件の異なる pg_stat_statements エントリとして保存できました。一方、PostgreSQL バージョン 17 以降では、これら 2 件のステートメントを単一のエントリとして格納します (例: SAVEPOINT $1)。詳細については、PostgreSQL のウェブサイトで pg_stat_statements を参照してください。

PostgreSQL バージョン 17 以降にアップグレードできない場合は、アプリケーション、オブジェクトリレーショナルマッパー (ORM)、およびデータベースドライバーが SAVEPOINT コマンドなどの SQL を自動的に発行していないかを確認してください。これらの自動 SAVEPOINT コマンドが原因で、pg_stat_statements エントリの数が増加する可能性があります。

割り当て解除が発生した回数を確認する

PostgreSQL バージョン 14 以降:

割り当て解除が発生した合計回数を確認するには、pg_stat_statements_info ビューで dealloc 列を確認します。その情報を参考に、pg_stat_statements.max を適切な値に調整してください。詳細については、PostgreSQL のウェブサイトで pg_stat_statements_info ビューを参照してください。

一定期間における割り当て解除回数を確認するには、pg_stat_statements_info ビューを定期的に選択し、pg_stat_statements_info.dealloc との差を計算します。

pg_stat_statements_info ビューを選択する際、「ERROR: relation 'pg_stat_statements_info' does not exist」というエラーメッセージが表示される可能性があります。このエラーは、pg_stat_statements はメモリへの読み込みのみが行われ、データベースにはインストールされていない場合に発生します。このエラーを解決するには、アプリケーションが接続するデータベースに pg_stat_statements 拡張機能をインストールします。データベースに接続した後、次の SQL ステートメントを実行し、pg_stat_statements をデータベースにインストールします。

CREATE EXTENSION pg_stat_statements;

詳細については、PostgreSQL のウェブサイトで「CREATE EXTENSION」を参照してください。

コメントはありません

関連するコンテンツ