LWLock:buffer_content (BufferContent) - Amazon Aurora
サポート対象エンジンバージョンContext待機時間が増加する原因の可能性アクション

LWLock:buffer_content (BufferContent)

このLWLock:buffer_content待機イベントは、セッションがデータページをメモリに読み取るまたは書き込むために待機中、他のセッションがそのページを書き込み用にロックしている場合に発生します。Aurora PostgreSQL 13 以降では、この待機イベントはBufferContentと呼ばれます。

サポート対象エンジンバージョン

この待機イベント情報は、Aurora PostgreSQL のすべてのバージョンでサポートされています。

Context

データの読み取りや操作のために、PostgreSQL は共有メモリバッファを介してデータにアクセスします。バッファから読み取るために、プロセスは共有モードでバッファコンテンツに対する軽量ロック (LwLock) を取得します。バッファに書き込むには、排他モードでそのロックを取得します。共有ロックを使用すると、他のプロセスがそのコンテンツの共有ロックを同時に取得できます。排他ロックは、他のプロセスによるいかなるタイプのロック取得も防ぎます。

LWLock:buffer_content (BufferContent) イベントは、複数のプロセスが特定のバッファの内容に対して軽量ロック (LWLocks) を取得しようとしていることを示します。

待機時間が増加する原因の可能性

LWLock:buffer_content (BufferContent) イベントが通常より頻繁に発生し、パフォーマンスの問題を示している可能性がある場合、代表的な原因として以下が挙げられます。

同一データに対する同時更新の増加

同じバッファコンテンツを更新するクエリによる同時実行セッションの数が増加する可能性があります。この競合は、インデックスの多いテーブルではより顕著になることがあります。

ワークロードデータがメモリ内に存在しない

アクティブなワークロードが処理しているデータがメモリ上にない場合、これらの待機イベントが増加する可能性があります。この効果は、ロックを保持しているプロセスが、ディスク I/O 操作の実行中にロックを長く維持できるためです。

外部キー制約の過度の使用

外部キー制約により、プロセスがバッファコンテンツロックを保持する時間を増やすことがあります。この効果は、読み取り操作では、そのキーが更新されている間、参照キーに対する共有バッファコンテンツのロックが必要になるためです。

アクション

待機イベントの原因に応じたさまざまなアクションをお勧めします。LWLock:buffer_content(BufferContent)イベントは、Amazon RDS Performance Insights を使用するか、ビューpg_stat_activityのクエリで特定することができます。

インメモリ効率の向上

アクティブなワークロードデータがメモリ内に存在する可能性を高めるには、テーブルをパーティション化するか、インスタンスクラスをスケールアップします。DB インスタンスクラスの詳細については、「Amazon Aurora DB インスタンスクラス」を参照してください。

BufferCacheHitRatio メトリクスをモニタリングします。このメトリクスは、DB クラスター内の DB インスタンスのバッファキャッシュによって処理されたリクエストの割合を測定します。このメトリクスにより、メモリで処理されているデータの量に関するインサイトを得られます。ヒット率が高い場合は、DB インスタンスには作業データセットに使用できる十分なメモリがあることを示します。低い場合は、クエリがストレージのデータに頻繁にアクセスしていることを示します。

PG Collector レポートの [Memory setting] セクションにあるテーブルあたりのキャッシュ読み取りヒットとインデックスあたりのキャッシュ読み取りヒットから、テーブルとインデックスのキャッシュヒット率に関するインサイトを得られます。

外部キー制約の使用を減らす

外部キー制約の使用で、LWLock:buffer_content(BufferContent)待機イベントが多発しているワークロードを調査します。不要な外部キーの制約を削除します。

未使用インデックスの削除

LWLock:buffer_content (BufferContent) 待機イベントが多いワークロードで、未使用のインデックスを特定して削除します。

PG Collector レポートの [Unused Indexes] セクションで、データベース内の未使用インデックスに関するインサイトを得られます。

重複インデックスを削除する

重複するインデックスを特定して削除します。

PG Collector レポートの [Duplicate indexes] セクションで、データベース内の重複インデックスに関するインサイトを得られます。

無効なインデックスを削除または再インデックスする

通常、無効なインデックスは CREATE INDEX CONCURRENTLY または REINDEX CONCURRENTLY の使用中に、コマンドの失敗や中止に伴って発生します。

無効なインデックスはクエリには使用できませんが、更新され、ディスク容量を消費します。

PG Collector レポートの [Invalid indexes] セクションで、データベース内の無効なインデックスに関するインサイトを得られます。

部分インデックスを使用する

部分インデックスを活用して、クエリのパフォーマンスを向上させ、インデックスのサイズを縮小できます。部分インデックスは、テーブルのサブセットに対して構築されるインデックスです。サブセットは条件式で定義します。部分インデックスに関するドキュメントで説明しているように、PostgreSQL はすべてのケースでインデックスを更新する必要がないため、部分インデックスはインデックスの維持に伴うオーバーヘッドを削減できます。

テーブルとインデックスの肥大化を解消する

テーブルとインデックスの過剰な肥大化は、データベースのパフォーマンスに悪影響を及ぼす可能性があります。テーブルとインデックスが肥大化すると、アクティブなワーキングセットのサイズが大きくなり、インメモリ効率が低下します。さらに、肥大化により、ストレージコストが増加し、クエリの実行が遅くなります。肥大化を診断するには、「診断テーブルとインデックスの肥大化」を参照してください。さらに、PG Collector レポートの [Fragmentation (Bloat)] セクションで、テーブルとインデックスの肥大化に関するインサイトを得られます。

テーブルとインデックスの肥大化に対処するには、いくつかのオプションがあります。

VACUUM FULL

VACUUM FULL はテーブルの新しいコピーを作成し、有効なタプルのみをコピーして、ACCESS EXCLUSIVE ロックを保持しながら古いテーブルを新しいテーブルに置き換えます。これにより、停止の原因となる可能性がある、テーブルに対する読み取りや書き込みを防止します。さらに、テーブルが大きい場合、VACUUM FULL には時間がかかります。

pg_repack

pg_repack は、VACUUM FULL が適切ではない可能性がある状況で役立ちます。肥大化したテーブルのデータを含む新しいテーブルを作成し、元のテーブルの変更を追跡して、元のテーブルを新しいテーブルに置き換えます。新しいテーブルの構築中は、元のテーブルに対する読み取りまたは書き込みオペレーションがロックされません。pg_repack の使用方法の詳細については、「Removing bloat with pg_repack」および「pg_repack」を参照してください。

REINDEX

REINDEX コマンドを活用してインデックスの肥大化に対処できます。REINDEX は、デッドページや空またはほぼ空のページを除いて、インデックスの新しいバージョンを書き込み、インデックスのスペース消費量を削減します。REINDEX コマンドの詳細については、REINDEX に関するドキュメントを参照してください。

テーブルとインデックスの肥大化の解消後に、これらのテーブルの自動バキューム頻度を高める必要が生じる場合があります。積極的な自動バキューム設定をテーブルレベルで実装すると、将来の肥大化を防ぐことができます。詳細については、Vacuuming and analyzing tables automatically に関するドキュメントを参照してください。