# LWLock:BufferIO (IPC:BufferIO)
<a name="wait-event.lwlockbufferio"></a>

`LWLock:BufferIO` イベントは、RDS for PostgreSQL が同時にページにアクセスしようとしているときに、他のプロセスが入出力 (I/O) オペレーションの完了を待っているときに発生します。その目的は、同じページを共有バッファに読み込むことです。

**Topics**
+ [関連するエンジンのバージョン](#wait-event.lwlockbufferio.context.supported)
+ [Context](#wait-event.lwlockbufferio.context)
+ [原因](#wait-event.lwlockbufferio.causes)
+ [アクション](#wait-event.lwlockbufferio.actions)

## 関連するエンジンのバージョン
<a name="wait-event.lwlockbufferio.context.supported"></a>

この待機イベント情報は、すべての RDS for PostgreSQL のバージョンに関連しています。RDS for PostgreSQL 12 以前のバージョンでは、この待機イベントは lwlock:buffer\$1io という名前でしたが、RDS for PostgreSQL 13 バージョンでは lwlock:bufferio という名前です。RDS for PostgreSQL 14 バージョンから、BufferIO 待機イベントは `LWLock` から `IPC` 待機イベントタイプ (IPC:BufferIO) に移動されました。

## Context
<a name="wait-event.lwlockbufferio.context"></a>

各共有バッファは、ブロック (またはページ) が共有バッファプールの外部で取得される必要があるたびに、`LWLock:BufferIO`待機イベントに関連付けられた I/O ロックを持ちます。

このロックは、すべての同じブロックへのアクセスを必要とする複数のセッションを処理するために使用されます。このブロックは、`shared_buffers`パラメータで定義された共有バッファプールの外部から読み取る必要があります。

共有バッファプール内でページが読み込まれると、`LWLock:BufferIO`ロックが解除されます。

**注記**  
`LWLock:BufferIO`待機イベントは[IO:DataFileRead](wait-event.iodatafileread.md)待機イベントに先行します。`IO:DataFileRead`待機イベントは、データがストレージから読み込まれている間に発生します。

ライトウェイトロックの詳細については、「[ロックの概要](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20)」を参照してください。

## 原因
<a name="wait-event.lwlockbufferio.causes"></a>

`LWLock:BufferIO`上位待機中に表示されるイベントの一般的な原因には、次のものがあります。
+ 複数のバックエンドまたは接続が I/O オペレーションを保留している同じページにアクセスしようとしている
+ 共有バッファプール (`shared_buffers`パラメータで定義) のサイズと、現在のワークロードが必要とするバッファ数の比率
+ 共有バッファプールのサイズが、他の操作によって削除されるページ数とのバランスが悪い
+ エンジンが共有バッファプールに必要以上のページを読み込む必要がある大規模なインデックスまたは肥大化したインデックス
+ DB エンジンが強制的に必要以上に多くのページをテーブルから読み取るインデックスの欠落
+ チェックポイント発生が頻繁すぎたり、変更されたページをフラッシュする必要が多すぎる
+ 同じページで操作を実行しようとするデータベース接続が突然スパイクする

## アクション
<a name="wait-event.lwlockbufferio.actions"></a>

待機イベントの原因に応じたさまざまなアクションを実行することをお勧めします。
+ `BufferCacheHitRatio`の急減と`LWLock:BufferIO`待機イベントの相関関係のため、Amazon CloudWatch メトリクスを観察します。この効果は、共有バッファの設定が小さいことを意味することがあります。増やすか、DB インスタンスクラスをスケールアップする必要がある場合があります。ワークロードをより多くのリーダーノードに分割できます。
+ `LWLock:BufferIO`が`BufferCacheHitRatio`のメトリックと一致する場合は、ワークロードのピーク時間に基づいて`max_wal_size`と`checkpoint_timeout`をチューニングしてください。次に、原因となっているクエリを特定します。
+ 未使用のインデックスがあるかどうかを確認し、それらを削除します。
+ パーティション化されたテーブルを使用します (パーティション化されたインデックスもあります)。これにより、インデックスの並べ替えを低く抑え、その影響を軽減することができます。
+ 不必要に列のインデックスを作成しないようにします。
+ 接続プールを使用して、突然のデータベース接続スパイクを防ぎます。
+ ベストプラクティスとして、データベースへの最大接続数を制限します。