# synch/mutex/innodb/fil\_system\_mutex
`synch/mutex/innodb/fil_system_mutex` 이벤트는 세션이 테이블스페이스 메모리 캐시에 액세스하려고 대기 중일 때 발생합니다.
**Topics**
+ [지원되는 엔진 버전](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [컨텍스트](#ams-waits.innodb-fil-system-mutex.context)
+ [대기 증가의 가능한 원인](#ams-waits.innodb-fil-system-mutex.causes)
+ [작업](#ams-waits.innodb-fil-system-mutex.actions)
## 지원되는 엔진 버전
이 대기 이벤트 정보는 다음 엔진 버전에서 지원됩니다.
+ Aurora MySQL 버전 2 및 3
## 컨텍스트
InnoDB는 테이블스페이스를 사용하여 테이블 및 로그 파일의 스토리지 영역을 관리합니다. *테이블스페이스 메모리 캐시(tablespace memory cache)*는 테이블스페이스에 대한 정보를 유지 관리하는 전역적 메모리 구조입니다. MySQL은 `synch/mutex/innodb/fil_system_mutex` 대기를 사용하여 테이블스페이스 메모리 캐시에 대한 동시 액세스를 제어합니다.
`synch/mutex/innodb/fil_system_mutex` 이벤트는 현재 동일한 테이블스페이스의 테이블스페이스 메모리 캐시 정보를 검색하고 조작해야 하는 작업이 두 개 이상임을 나타냅니다.
## 대기 증가의 가능한 원인
`synch/mutex/innodb/fil_system_mutex` 이벤트가 정상보다 더 많이 나타나 성능 문제를 나타낼 수 있는 경우는 일반적으로 다음 조건이 모두 충족된 경우에 발생합니다.
+ 동일한 테이블에서 데이터를 업데이트하거나 삭제하는 동시 데이터 조작 언어(DML) 작업이 늘어납니다.
+ 이 테이블의 테이블스페이스는 매우 크며, 많은 데이터 페이지가 있습니다.
+ 이러한 데이터 페이지의 채우기 비율은 낮습니다.
## 작업
대기 이벤트의 원인에 따라 다른 작업을 권장합니다.
**Topics**
+ [이벤트를 일으키는 세션 및 쿼리 식별](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [사용량이 적은 시간대에 대형 테이블 재구성](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### 이벤트를 일으키는 세션 및 쿼리 식별
일반적으로 보통 로드에서 중요 로드까지 있는 데이터베이스에는 대기 이벤트가 있습니다. 성능이 최적이면 대기 이벤트가 허용될 수 있습니다. 성능이 최적이 아닌 경우 데이터베이스가 가장 많은 시간을 소비하는 위치를 확인합니다. 가장 높은 로드를 일으키는 대기 이벤트를 살펴보고 데이터베이스와 애플리케이션을 최적화하여 이러한 이벤트를 줄일 수 있는지 확인합니다.
**높은 로드에 책임이 있는 SQL 쿼리를 찾으려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **Performance Insights**(성능 개선 도우미)를 선택합니다.
1. DB 인스턴스를 선택합니다. 해당 DB 인스턴스에 대해 성능 개선 도우미 대시보드가 표시됩니다.
1. **데이터베이스 로드(Database load)** 차트에서 **대기별 조각(Slice by wait)**을 선택합니다.
1. 페이지 하단에서 **상위 SQL(Top SQL)**을 선택합니다.
차트에는 로드에 책임이 있는 SQL 쿼리가 나열됩니다. 목록의 맨 위에 있는 쿼리가 가장 큰 책임이 있습니다. 병목 현상을 해결하려면 다음 명령문에 집중하세요.
성능 개선 도우미를 통한 문제 해결의 개요는 블로그 게시물, [성능 개선 도우미를 통해 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
```
### 사용량이 적은 시간대에 대형 테이블 재구성
프로덕션 시간대 이외의 유지 관리 기간 동안 많은 수의 `synch/mutex/innodb/fil_system_mutex` 대기 이벤트 소스로 식별되는 대형 테이블을 재구성합니다. 이렇게 하면 테이블에 대한 빠른 액세스가 중요한 경우 내부 테이블스페이스 맵 정리가 수행되지 않아야 합니다. 테이블 재구성에 대한 자세한 내용은 *MySQL 참조*의 [OPTIMIZE TABLE 문](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html)을 참조하세요.