# synch/mutex/innodb/fil\$1system\$1mutex
<a name="ams-waits.innodb-fil-system-mutex"></a>

`synch/mutex/innodb/fil_system_mutex` イベントは、セッションがテーブルスペースのメモリキャッシュへのアクセスを待っているときに発生します。

**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Context](#ams-waits.innodb-fil-system-mutex.context)
+ [待ち時間増加の考えられる原因](#ams-waits.innodb-fil-system-mutex.causes)
+ [アクション](#ams-waits.innodb-fil-system-mutex.actions)

## サポート対象エンジンバージョン
<a name="ams-waits.innodb-fil-system-mutex.context.supported"></a>

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

## Context
<a name="ams-waits.innodb-fil-system-mutex.context"></a>

InnoDB はテーブルスペースを使用して、テーブルとログファイルのストレージ領域を管理します。*テーブルスペースのメモリキャッシュ*は、テーブルスペースに関する情報を保持するグローバル・メモリ構造です。MySQL は `synch/mutex/innodb/fil_system_mutex` 待機を使用して、テーブルスペースのメモリー・キャッシュへの同時アクセスを制御します。

イベント `synch/mutex/innodb/fil_system_mutex` は、テーブルスペースメモリーキャッシュにある情報を、同じテーブルスペースに対して取得または操作しないといけないオペレーションが現在複数存在することを示します。

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

`synch/mutex/innodb/fil_system_mutex` イベントが通常よりも多く表示され、パフォーマンスの問題を示している可能性がある場合、典型的な原因は次のとおりです。
+ 同じテーブル内のデータを更新または削除する、同時データ操作言語 (DML) オペレーションの増加。
+ このテーブルのテーブルスペースは非常に大きく、多くのデータページがあります。
+ これらのデータページの塗りつぶし係数は低いです。

## アクション
<a name="ams-waits.innodb-fil-system-mutex.actions"></a>

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

**Topics**
+ [イベントの原因となるセッションとクエリを特定する](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [オフピーク時に大きなテーブルを再編成する](#ams-waits.innodb-fil-system-mutex.actions.reorganize)

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

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

**高ロードの原因となる SQL クエリを検索するには**

1. AWS マネジメントコンソール にサインインし、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/) を参照してください。

どのクエリが多数の`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
```

### オフピーク時に大きなテーブルを再編成する
<a name="ams-waits.innodb-fil-system-mutex.actions.reorganize"></a>

本番時間外のメンテナンスウィンドウで、多数の `synch/mutex/innodb/fil_system_mutex` 待機イベントの出典として識別するラージテーブルを再編成する。これにより、テーブルへのクイックアクセスが必修な際に、内部テーブルスペースマップのクリーンアップが行われないようにします。テーブルの再編成については、*MySQL リファレンス*の [TABLE ステートメントの最適化](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html)を参照してください。