# synch/mutex/innodb/trx\$1sys\$1mutex
<a name="ams-waits.trxsysmutex"></a>

`synch/mutex/innodb/trx_sys_mutex` 이벤트는 많은 트랜잭션 수가 있는 데이터베이스 작업이 많을 때 발생합니다.

**Topics**
+ [

## 관련 엔진 버전
](#ams-waits.trxsysmutex.context.supported)
+ [

## 컨텍스트
](#ams-waits.trxsysmutex.context)
+ [

## 대기 증가의 가능한 원인
](#ams-waits.trxsysmutex.causes)
+ [

## 작업
](#ams-waits.trxsysmutex.actions)

## 관련 엔진 버전
<a name="ams-waits.trxsysmutex.context.supported"></a>

이 대기 이벤트 정보는 다음 엔진 버전에서 지원됩니다.
+ Aurora MySQL 버전 2 및 3

## 컨텍스트
<a name="ams-waits.trxsysmutex.context"></a>

내부적으로 InnoDB 데이터베이스 엔진은 스냅샷을 통해 반복 가능한 읽기 격리 수준을 사용하여 읽기 일관성을 유지합니다. 이렇게 하면 스냅샷이 생성될 때 데이터베이스의 특정 시점 보기가 제공됩니다.

InnoDB에서는 변경 사항이 커밋되었는지 여부와 관계없이 모든 변경 사항이 도착하자마자 데이터베이스에 적용됩니다. 이 방법은 다중 버전 동시성 제어(MVCC)가 없으면 데이터베이스에 연결된 모든 사용자가 모든 변경 사항 및 최신 행을 볼 수 있음을 의미합니다. 따라서 InnoDB는 필요한 경우 롤백해야 할 내용을 이해하기 위해 변경 사항을 추적하는 방법이 필요합니다.

이렇게 하려면 InnoDB는 트랜잭션 시스템(`trx_sys`)을 사용하여 스냅샷을 추적합니다. 트랜잭션 시스템은 다음 작업을 수행합니다.
+ 실행 취소 로그의 각 행에 대한 트랜잭션 ID를 추적합니다.
+ `ReadView`라는 내부 InnoDB 구조를 사용하여 스냅샷에 표시되는 트랜잭션 ID를 식별하는 데 도움을 줄 수 있습니다.

## 대기 증가의 가능한 원인
<a name="ams-waits.trxsysmutex.causes"></a>

트랜잭션 ID의 일관되고 제어된 처리(생성, 읽기, 업데이트 및 삭제)가 필요한 모든 데이터베이스 작업은 `trx_sys`의 호출을 뮤텍스로 생성합니다.

이러한 호출은 세 가지 기능 내에서 발생합니다.
+ `trx_sys_mutex_enter` - 뮤텍스를 생성합니다.
+ `trx_sys_mutex_exit` - 뮤텍스를 해제합니다.
+ `trx_sys_mutex_own` - 뮤텍스 소유 여부를 테스트합니다.

InnoDB 성능 스키마 계측은 모든 `trx_sys` 뮤텍스 호출을 추적합니다. 추적에는 데이터베이스 시작 또는 종료, 롤백 작업, 정리 실행 취소, 행 읽기 액세스 및 버퍼 풀 로드 시 `trx_sys`의 관리가 포함되지만 이에 국한되지는 않습니다. 많은 수의 트랜잭션을 통한 데이터베이스 작업이 많으면 `synch/mutex/innodb/trx_sys_mutex`가 상위 대기 이벤트에 표시됩니다.

자세한 내용은 MySQL 설명서의 [성능 스키마를 사용하여 InnoDB 뮤텍스 대기 모니터링](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html)을 참조하세요.

## 작업
<a name="ams-waits.trxsysmutex.actions"></a>

대기 이벤트의 원인에 따라 다른 작업을 권장합니다.

**Topics**
+ [

### 이벤트를 일으키는 세션 및 쿼리 식별
](#ams-waits.trxsysmutex.actions.identify)
+ [

### 다른 대기 이벤트 검사
](#ams-waits.trxsysmutex.actions.action1)

### 이벤트를 일으키는 세션 및 쿼리 식별
<a name="ams-waits.trxsysmutex.actions.identify"></a>

일반적으로 보통 로드에서 중요 로드까지 있는 데이터베이스에는 대기 이벤트가 있습니다. 성능이 최적이면 대기 이벤트가 허용될 수 있습니다. 성능이 최적이 아닌 경우 데이터베이스가 가장 많은 시간을 소비하는 위치를 확인합니다. 가장 큰 로드에 기여하는 대기 이벤트를 살펴보세요. 데이터베이스와 애플리케이션을 최적화하여 이러한 이벤트를 줄일 수 있는지 확인합니다.

**AWS Management Console에서 상위 SQL 차트를 보려면**

1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.

1. 탐색 창에서 **성능 개선 도우미**을 선택합니다.

1. DB 인스턴스를 선택합니다. DB 인스턴스에 대한 성능 개선 도우미 대시보드가 표시됩니다.

1. **데이터베이스 로드(Database load)** 차트에서 **대기별 조각(Slice by wait)**을 선택합니다.

1. **데이터베이스 로드(Database load)** 차트에서 **상위 SQL(Top SQL)**을 선택합니다.

   차트에는 로드에 책임이 있는 SQL 쿼리가 나열됩니다. 목록의 맨 위에 있는 쿼리가 가장 큰 책임이 있습니다. 병목 현상을 해결하려면 다음 명령문에 집중하세요.

성능 개선 도우미를 통한 문제 해결의 개요는 블로그 게시물, [성능 개선 도우미를 통해 Amazon Aurora MySQL 워크로드 분석](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)을 참조하세요.

### 다른 대기 이벤트 검사
<a name="ams-waits.trxsysmutex.actions.action1"></a>

`synch/mutex/innodb/trx_sys_mutex` 대기 이벤트와 연결된 다른 대기 이벤트를 검사합니다. 이렇게 하면 워크로드의 특성에 대해 추가 정보를 얻을 수 있습니다. 트랜잭션이 많으면 처리량이 줄어들 수 있지만 워크로드로 인해 이 작업이 필요할 수도 있습니다.

트랜잭션 최적화 방법에 대한 자세한 내용은 MySQL 설명서에서 [InnoDB 트랜잭션 관리 최적화](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)를 참조하세요.