# synch/mutex/innodb/buf\_pool\_mutex
<a name="ams-waits.bufpoolmutex"></a>

`synch/mutex/innodb/buf_pool_mutex` イベントは、スレッドがメモリ内のページにアクセスするために InnoDB バッファプールのロックを取得したときに発生します。

**Topics**
+ [関連するエンジンバージョン](#ams-waits.bufpoolmutex.context.supported)
+ [Context](#ams-waits.bufpoolmutex.context)
+ [待ち時間増加の考えられる原因](#ams-waits.bufpoolmutex.causes)
+ [アクション](#ams-waits.bufpoolmutex.actions)

## 関連するエンジンバージョン
<a name="ams-waits.bufpoolmutex.context.supported"></a>

この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2

## Context
<a name="ams-waits.bufpoolmutex.context"></a>

`buf_pool` ミューテックスは、バッファプールの制御データ構造を保護する単一のミューテックスです。

詳細については、MySQL ドキュメントの[パフォーマンススキーマを使用した InnoDB Mutex 待機をモニタリングする](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html)を参照してください。

## 待ち時間増加の考えられる原因
<a name="ams-waits.bufpoolmutex.causes"></a>

これは、ワークロード固有の待機イベントです。`synch/mutex/innodb/buf_pool_mutex` がトップ待機イベント内に出現する一般的な原因は、次のような場合が含まれます。
+ バッファープールのサイズが、ワーキングデータセットを保持するのに十分な大きさではない。
+ ワークロードが、データベース内の特定のテーブルの特定のページに固有であり、バッファプール内に競合が発生ている。

## アクション
<a name="ams-waits.bufpoolmutex.actions"></a>

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

**Topics**
+ [イベントの原因となるセッションとクエリを特定する](#ams-waits.bufpoolmutex.actions.identify)
+ [Performance Insights の使用](#ams-waits.bufpoolmutex.actions.action1)
+ [Aurora レプリカの作成](#ams-waits.bufpoolmutex.actions.action2)
+ [バッファープールサイズの検査](#ams-waits.bufpoolmutex.actions.action3)
+ [グローバルステータス履歴をモニタリングする](#ams-waits.bufpoolmutex.actions.action4)

### イベントの原因となるセッションとクエリを特定する
<a name="ams-waits.bufpoolmutex.actions.identify"></a>

通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。

**AWSマネジメントコンソールの トップ SQL チャートを表示するには**

1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。

1. ナビゲーションペインで、[**Performance Insights**] を選択します。

1. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。

1. **データベースロード**で、**待機でスライス**を選択します。

1. **データベースロード**グラフの下で、**トップ SQL** を選択します。

   グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。

Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。

### Performance Insights の使用
<a name="ams-waits.bufpoolmutex.actions.action1"></a>

このイベントはワークロードに関連しています。Performance Insights を使用して、以下を実行できます。
+ 待機イベントがスタートされたタイミングと、その時点でアプリケーションログまたは関連出典からのワークロードに変化があったかどうかを特定します。
+ この待機イベントの原因になっている SQL ステートメントを特定します。クエリの実行プランを調べて、これらのクエリが最適化され、適切なインデックスが使用されていることを確認します。

  待機イベントの原因となる上位クエリが同じデータベースオブジェクトまたはテーブルに関連付けられている場合は、そのオブジェクトまたはテーブルをパーティション化することを検討してください。

### Aurora レプリカの作成
<a name="ams-waits.bufpoolmutex.actions.action2"></a>

Aurora レプリカを作成して、読み取り専用トラフィックを処理できます。Aurora オートスケーリングを使用して、読み取りトラフィックのサージを処理することもできます。Aurora レプリカでスケジュールされた読み取り専用タスクと論理的なバックアップを実行してください。

詳細については、「[Aurora レプリカでの Amazon Aurora Auto Scaling](Aurora.Integrating.AutoScaling.md)」を参照してください。

### バッファープールサイズの検査
<a name="ams-waits.bufpoolmutex.actions.action3"></a>

メトリクス `innodb_buffer_pool_wait_free` を確認して、バッファ・プール・サイズがワークロードに十分かどうかをチェックします。このメトリクスの値が高く継続的に増加している場合は、バッファ・プールのサイズがワークロードを処理するのに十分でないことを示します。`innodb_buffer_pool_size` が適切に設定されている場合、`innodb_buffer_pool_wait_free` の値は小さくなります。詳細については、MySQL ドキュメントの[Innodb\_buffer\_pool\_wait\_free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free)を参照してください。

DB インスタンス上に、セッションバッファとオペレーティングシステムのタスクに十分なメモリがある場合は、バッファプールサイズを増やします。そうでない場合は、DB インスタンスを大きな DB インスタンスクラスに変更して、バッファプールに割り当てられる追加のメモリを取得します。

**注記**  
Aurora MySQL は、構成された `innodb_buffer_pool_size` に基づいて`innodb_buffer_pool_instances` の値を自動的に調整します

### グローバルステータス履歴をモニタリングする
<a name="ams-waits.bufpoolmutex.actions.action4"></a>

ステータス可変の変更率をモニタリングすることで、DB インスタンスのロックまたはメモリの問題を検出できます。グローバルステータス履歴 (GoSH) がまだオンになっていない場合は、オンにします。GoSH の詳細については、[グローバルステータス履歴の管理](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH)を参照してください。

カスタムの Amazon CloudWatch メトリクスを作成して、ステータス可変をモニタリングすることもできます。詳細については、[カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)を参照してください。