synch/mutex/innodb/temp_pool_manager_mutex - Amazon Aurora
지원되는 엔진 버전컨텍스트대기 증가의 가능한 원인작업

synch/mutex/innodb/temp_pool_manager_mutex

synch/mutex/innodb/temp_pool_manager_mutex 대기 이벤트는 세션이 세션 임시 테이블스페이스 풀 관리를 위한 뮤텍스 획득을 기다리고 있을 때 발생합니다.

지원되는 엔진 버전

이 대기 이벤트 정보는 다음 엔진 버전에서 지원됩니다.

  • Aurora MySQL 버전 3

컨텍스트

Aurora MySQL 버전 3.x 이상은 temp_pool_manager_mutex를 사용하여 임시 테이블스페이스 풀에 동시에 액세스하는 여러 세션을 제어합니다. Aurora MySQL은 영구 데이터의 경우 Aurora 클러스터 볼륨을 통해 스토리지를 관리하고 임시 파일의 경우 로컬 스토리지를 관리합니다. 세션이 Aurora 클러스터 볼륨에 임시 테이블을 생성할 때 임시 테이블스페이스가 필요합니다.

세션이 처음으로 임시 테이블스페이스를 요청하면 MySQL은 공유 풀에서 세션 임시 테이블스페이스를 할당합니다. 세션은 다음 테이블 유형에 대해 한 번에 최대 2개의 임시 테이블스페이스를 포함할 수 있습니다.

  • 사용자가 생성한 임시 테이블

  • 옵티마이저 생성 내부 임시 테이블

기본 TempTable 엔진은 다음 오버플로 메커니즘을 사용하여 임시 테이블을 처리합니다.

  • 최대 temptable_max_ram 한도까지 RAM에 테이블을 저장합니다.

  • RAM이 가득 차면 로컬 스토리지의 메모리 매핑 파일로 이동합니다.

  • 메모리 매핑 파일이 temptable_max_mmap 제한에 도달하면 공유 클러스터 볼륨을 사용합니다.

임시 테이블이 RAM 및 로컬 스토리지 제한을 모두 초과하면 MySQL은 온디스크 테이블스페이스를 사용하여 관리합니다.

세션에 온디스크 임시 테이블이 필요한 경우 MySQL은 다음을 수행합니다.

  • 풀에서 재사용할 수 있는 INACTIVE 테이블스페이스를 찾습니다.

  • INACTIVE 공백이 없는 경우 10개의 새 테이블스페이스를 생성합니다.

세션 연결이 끊어지면 MySQL은 다음을 수행합니다.

  • 세션의 임시 테이블스페이스를 자릅니다.

  • 재사용을 위해 풀에서 비활성으로 표시합니다.

  • 서버가 다시 시작될 때까지 현재 풀 크기를 유지합니다.

  • 다시 시작한 후 기본 풀 크기(테이블스페이스 10개)로 돌아갑니다.

대기 증가의 가능한 원인

이 대기 이벤트를 유발하는 일반적인 상황:

  • 클러스터 볼륨에 내부 임시 테이블을 생성하는 동시 세션입니다.

  • 클러스터 볼륨에 사용자 임시 테이블을 생성하는 동시 세션입니다.

  • 활성 테이블스페이스를 사용하여 세션이 갑자기 종료되었습니다.

  • 쓰기 워크로드가 많은 동안 테이블스페이스 풀 확장.

  • INFORMATION_SCHEMA.에 액세스하는 동시 쿼리

작업

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

임시 테이블 사용량 모니터링 및 최적화

임시 테이블 사용량을 모니터링하고 최적화하려면 다음 방법 중 하나를 사용합니다.

  • Performance Insights의 Created_tmp_disk_tables 카운터를 확인하여 Aurora 클러스터에서 온디스크 임시 테이블 생성을 추적합니다.

  • 데이터베이스에서 mysql> show status like '%created_tmp_disk%' 명령을 실행하여 임시 테이블 생성을 직접 모니터링합니다.

참고

임시 테이블 동작은 Aurora MySQL 리더 노드와 라이터 노드 간에 다릅니다. 자세한 내용은 Aurora MySQL 버전 3의 새로운 임시 테이블 동작 섹션을 참조하세요.

임시 테이블을 생성하는 쿼리를 식별한 후 다음 최적화 단계를 수행합니다.

  • EXPLAIN을 사용하여 쿼리 실행 계획을 검사하고, 임시 테이블이 생성되는 위치와 이유를 식별합니다.

  • 가능한 경우 쿼리를 수정하여 임시 테이블 사용량을 줄입니다.

쿼리 최적화만으로 성능 문제가 해결되지 않는 경우 다음 구성 파라미터를 조정하는 것이 좋습니다.

  • temptable_max_ram - 임시 테이블의 최대 RAM 사용량을 제어합니다.

  • temptable_max_mmap - 메모리 매핑 파일 스토리지의 제한을 설정합니다.

  • tmp_table_size - aurora_tmptable_enable_per_table_limit이 활성화된 경우 적용됩니다(기본적으로 비활성화됨).

중요

특정 쿼리 조건에는 구성 설정에 관계없이 항상 온디스크 임시 테이블이 필요합니다. TempTable 스토리지 엔진에 대한 자세한 내용은 Amazon RDS for MySQL 및 Amazon Aurora MySQL의 TempTable 스토리지 엔진 사용을 참조하세요.

INFORMATION_SCHEMA를 사용하여 쿼리 검토

INFORMATION_SCHEMA 테이블을 쿼리할 때 MySQL은 클러스터 볼륨에 InnoDB 임시 테이블을 생성합니다. 각 세션에는 이러한 테이블에 대한 임시 테이블스페이스가 필요하므로, 동시 액세스가 높을 때 성능 문제가 발생할 수 있습니다.

성능 개선:

  • 가능한 경우 INFORMATION_SCHEMA 대신 PERFORMANCE_SCHEMA를 사용합니다.

  • INFORMATION_SCHEMA를 사용해야 하는 경우 이러한 쿼리를 실행하는 빈도를 줄입니다.

innodb_sync_array_size 파라미터 증가

innodb_sync_array_size 파라미터는 MySQL에서 뮤텍스/잠금 대기 배열의 크기를 제어합니다. 1의 기본값은 일반 워크로드에서 작동하지만, 이 값을 늘리면 높은 동시성 중에 스레드 경합을 줄일 수 있습니다.

워크로드에 대기 스레드 수가 증가하는 것으로 표시되는 경우:

  • 워크로드에서 대기 중인 스레드 수를 모니터링합니다.

  • 스레드 조정 구조를 분할하고 경합을 줄이려면 innodb_sync_array_size를 인스턴스의 vCPU 수보다 크거나 같게 설정합니다.

참고

RDS 인스턴스에서 사용 가능한 vCPUs 수를 확인하려면 Amazon RDS 인스턴스 유형의 vCPU 사양을 참조하세요.

연결 풀링 구현

MySQL은 임시 테이블을 생성하는 각 세션에 전용 테이블스페이스를 할당합니다. 이 테이블스페이스는 데이터베이스 연결이 종료될 때까지 활성 상태로 유지됩니다. 리소스를 보다 효율적으로 관리:

  • 연결 풀링을 구현하여 활성 임시 테이블스페이스 수를 제한합니다.

  • 각 작업에 대해 새 연결을 생성하는 대신 기존 연결을 재사용합니다.