synch/mutex/innodb/fil_system_mutex
synch/mutex/innodb/fil_system_mutex イベントは、セッションがテーブルスペースのメモリキャッシュへのアクセスを待っているときに発生します。
サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
-
Aurora MySQL バージョン 2 および 3
Context
InnoDB はテーブルスペースを使用して、テーブルとログファイルのストレージ領域を管理します。テーブルスペースのメモリキャッシュは、テーブルスペースに関する情報を保持するグローバル・メモリ構造です。MySQL は synch/mutex/innodb/fil_system_mutex 待機を使用して、テーブルスペースのメモリー・キャッシュへの同時アクセスを制御します。
イベント synch/mutex/innodb/fil_system_mutex は、テーブルスペースメモリーキャッシュにある情報を、同じテーブルスペースに対して取得または操作しないといけないオペレーションが現在複数存在することを示します。
待ち時間増加の考えられる原因
synch/mutex/innodb/fil_system_mutex イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
同じテーブル内のデータを更新または削除する、同時データ操作言語 (DML) オペレーションの増加。
このテーブルのテーブルスペースは非常に大きく、多くのデータページがあります。
これらのデータページの塗りつぶし係数は低いです。
アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
イベントの原因となるセッションとクエリを特定する
通常、ロードが中程度から重大なデータベースには、待機イベントがあります。パフォーマンスが最適であれば、待機イベントは受け入れられる可能性があります。パフォーマンスが最適でない場合は、データベースが最も長い時間を費やしている場所を調べます。最も高いロードに寄与する待機イベントを調べて、データベースとアプリケーションを最適化してこれらのイベントを削減できるかどうかを調べます。
高ロードの原因となる SQL クエリを検索するには
AWS Management Console にサインインし、Amazon RDS コンソール https://console.aws.amazon.com/rds/
を開きます。 -
ナビゲーションペインで、[Performance Insights] を選択します。
-
DB インスタンスを選択します。この DB インスタンスに Performance Insights ダッシュボードが表示されます。
-
データベースロードで、待機でスライスを選択します。
-
ページの下部で トップ SQL を選択します。
グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析
どのクエリが多数のsynch/mutex/innodb/fil_system_mutex 待機原因になっているかを調べる別の方法は、、以下の例のように performance_schema をチェックする方法です。
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G *************************** 1. row *************************** THREAD_ID: 19 EVENT_ID: 195057 END_EVENT_ID: 195057 EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:6700 TIMER_START: 1010146190118400 TIMER_END: 1010146196524000 TIMER_WAIT: 6405600 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: NULL NESTING_EVENT_TYPE: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL *************************** 2. row *************************** THREAD_ID: 23 EVENT_ID: 5480 END_EVENT_ID: 5480 EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:5906 TIMER_START: 995269979908800 TIMER_END: 995269980159200 TIMER_WAIT: 250400 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: NULL NESTING_EVENT_TYPE: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL *************************** 3. row *************************** THREAD_ID: 55 EVENT_ID: 23233794 END_EVENT_ID: NULL EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex SOURCE: fil0fil.cc:449 TIMER_START: 1010492125341600 TIMER_END: 1010494304900000 TIMER_WAIT: 2179558400 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL INDEX_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 47285552262176 NESTING_EVENT_ID: 23233786 NESTING_EVENT_TYPE: WAIT OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: NULL
オフピーク時に大きなテーブルを再編成する
本番時間外のメンテナンスウィンドウで、多数の synch/mutex/innodb/fil_system_mutex 待機イベントの出典として識別するラージテーブルを再編成する。これにより、テーブルへのクイックアクセスが必修な際に、内部テーブルスペースマップのクリーンアップが行われないようにします。テーブルの再編成については、MySQL リファレンスの TABLE ステートメントの最適化
