# LWLock:buffer\$1mapping
<a name="apg-waits.lwl-buffer-mapping"></a>

このイベントは、セッションがデータブロックを共有バッファプール内のバッファに関連付けるのを待っているときに発生します。

**注記**  
この待機イベントは、Aurora PostgreSQL バージョン 12 以降では`LWLock:buffer_mapping`、バージョン 13 以降では`LWLock:BufferMapping`として発生します。

**Topics**
+ [

## サポート対象エンジンバージョン
](#apg-waits.lwl-buffer-mapping.context.supported)
+ [

## Context
](#apg-waits.lwl-buffer-mapping.context)
+ [

## 原因
](#apg-waits.lwl-buffer-mapping.causes)
+ [

## アクション
](#apg-waits.lwl-buffer-mapping.actions)

## サポート対象エンジンバージョン
<a name="apg-waits.lwl-buffer-mapping.context.supported"></a>

この待機イベント情報は、Aurora PostgreSQL バージョン 9.6 以降に関連します。

## Context
<a name="apg-waits.lwl-buffer-mapping.context"></a>

*共有バッファプール*は、プロセスで使用されている、または使用されていたすべてのページを保持する Aurora PostgreSQL メモリ領域です。プロセスがページを必要とするとき、そのページを共有バッファプールに読み取ります。`shared_buffers`パラメータは、共有バッファサイズを設定し、テーブルとインデックスページを格納するためのメモリ領域を予約します。このパラメータを変更する場合は、必ずデータベースを再起動してください。詳細については、「[共有バッファ](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.buffer-pool)」を参照してください。

`LWLock:buffer_mapping`待機イベントは、以下の場合に発生します。
+ プロセスは、バッファテーブルでページを検索し、共有バッファマッピングロックを取得します。
+ プロセスは、ページをバッファプールにロードし、排他的バッファマッピングロックを取得します。
+ プロセスは、プールからページを削除し、排他バッファマッピングロックを取得します。

## 原因
<a name="apg-waits.lwl-buffer-mapping.causes"></a>

このイベントが通常よりも頻繁に発生する場合、パフォーマンスの問題を示していることがあり、データベースは共有バッファプールにページインとアウトページングを行っています。代表的な原因としては、以下が挙げられます。
+ 大きなクエリ
+ 肥大化したインデックスとテーブル
+ フルテーブルスキャン
+ ワーキングセットより小さい共有プールサイズ

## アクション
<a name="apg-waits.lwl-buffer-mapping.actions"></a>

待機イベントの原因に応じたさまざまなアクションをお勧めします。

**Topics**
+ [

### バッファ関連のメトリクスをモニタリングする
](#apg-waits.lwl-buffer-mapping.actions.monitor-metrics)
+ [

### インデックス作成戦略を評価する
](#apg-waits.lwl-buffer-mapping.actions.indexes)
+ [

### 迅速に確保しなければならないバッファの数を減らす
](#apg-waits.lwl-buffer-mapping.actions.buffers)

### バッファ関連のメトリクスをモニタリングする
<a name="apg-waits.lwl-buffer-mapping.actions.monitor-metrics"></a>

`LWLock:buffer_mapping`がスパイクを待機したら、バッファヒット率を調べます。これらのメトリクスを使用すると、バッファキャッシュで何が起こっているかをより深く理解できます。次のメトリックを検証します。

`BufferCacheHitRatio`  
この Amazon CloudWatch のメトリクスは、DB クラスター内の DB インスタンスのバッファキャッシュによって処理されるリクエストの割合を測定します。この指標は、`LWLock:buffer_mapping`待機イベントまでの間に減少することがあります。

`blks_hit`  
この Performance Insights カウンターメトリクスは、共有バッファプールから取得されたブロックの数を示します。`LWLock:buffer_mapping`の待機イベントが表示された後、`blks_hit`のスパイクを観察することがあります。

`blks_read`  
この Performance Insights カウンターメトリクスは、共有バッファプールへの読み取りのため、 I/O を必要とするブロックの数を示します。`LWLock:buffer_mapping`待機イベントまでに`blks_read`のスパイクが観察されることがあります。

### インデックス作成戦略を評価する
<a name="apg-waits.lwl-buffer-mapping.actions.indexes"></a>

インデックス作成戦略がパフォーマンスが低下させていないことを確認するには、次を確認してください。

インデックスの肥大化  
インデックスとテーブルの肥大化によって、不要なページが共有バッファに読み込まれないようにします。テーブルに未使用の行がある場合は、データをアーカイブし、テーブルから行を削除することを検討してください。その後、サイズ変更されたテーブルのインデックスを再構築できます。

頻繁に使用するクエリのインデックス  
最適なインデックスがあるかどうかを判断するには、Performance Insights で DB エンジンのメトリクスをモニタリングします。`tup_returned`メトリクスは、読み込まれた行数を示します。`tup_fetched`メトリクスは、クライアントに返される行数を示します。`tup_returned`が`tup_fetched`を大幅に超える場合、データが適切にインデックスされていない可能性があります。また、テーブルの統計が最新ではない可能性があります。

### 迅速に確保しなければならないバッファの数を減らす
<a name="apg-waits.lwl-buffer-mapping.actions.buffers"></a>

`LWLock:buffer_mapping`待機イベントを減らすには、迅速に割り当てる必要があるバッファの数を減らしてください。1 つの戦略として、より小規模なバッチオペレーションを実行します。テーブルをパーティション化することで、より小さなバッチを実現できることがあります。