synch/mutex/innodb/buf_pool_mutex - Amazon Aurora
関連するエンジンバージョンContext待ち時間増加の考えられる原因アクション

synch/mutex/innodb/buf_pool_mutex

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

関連するエンジンバージョン

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

  • Aurora MySQL バージョン 2

Context

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

詳細については、MySQL ドキュメントのパフォーマンススキーマを使用した InnoDB Mutex 待機をモニタリングするを参照してください。

待ち時間増加の考えられる原因

これは、ワークロード固有の待機イベントです。synch/mutex/innodb/buf_pool_mutex がトップ待機イベント内に出現する一般的な原因は、次のような場合が含まれます。

  • バッファープールのサイズが、ワーキングデータセットを保持するのに十分な大きさではない。

  • ワークロードが、データベース内の特定のテーブルの特定のページに固有であり、バッファプール内に競合が発生ている。

アクション

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

イベントの原因となるセッションとクエリを特定する

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

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

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

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

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

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

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

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

Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析 を参照してください。

Performance Insights の使用

このイベントはワークロードに関連しています。Performance Insights を使用して、以下を実行できます。

  • 待機イベントがスタートされたタイミングと、その時点でアプリケーションログまたは関連出典からのワークロードに変化があったかどうかを特定します。

  • この待機イベントの原因になっている SQL ステートメントを特定します。クエリの実行プランを調べて、これらのクエリが最適化され、適切なインデックスが使用されていることを確認します。

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

Aurora レプリカの作成

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

詳細については、「Aurora レプリカでの Amazon Aurora Auto Scaling の使用」を参照してください。

バッファープールサイズの検査

メトリクス innodb_buffer_pool_wait_free を確認して、バッファ・プール・サイズがワークロードに十分かどうかをチェックします。このメトリクスの値が高く継続的に増加している場合は、バッファ・プールのサイズがワークロードを処理するのに十分でないことを示します。innodb_buffer_pool_size が適切に設定されている場合、innodb_buffer_pool_wait_free の値は小さくなります。詳細については、MySQL ドキュメントのInnodb_buffer_pool_wait_freeを参照してください。

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

注記

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

グローバルステータス履歴をモニタリングする

ステータス可変の変更率をモニタリングすることで、DB インスタンスのロックまたはメモリの問題を検出できます。グローバルステータス履歴 (GoSH) がまだオンになっていない場合は、オンにします。GoSH の詳細については、グローバルステータス履歴の管理を参照してください。

カスタムの Amazon CloudWatch メトリクスを作成して、ステータス可変をモニタリングすることもできます。詳細については、カスタムメトリクスの発行を参照してください。