MySQL DB 인스턴스에 Performance Insights의 SYNCH 대기 이벤트를 기다리는 많은 수의 활성 세션이 표시되는 이유는 무엇입니까?

간략한 설명

Performance Insights의 MySQL SYNCH 대기 이벤트는 여러 데이터베이스 세션이 동일한 보호 객체 또는 메모리 구조에 액세스할 때 발생합니다. Amazon Relational Database Service(Amazon RDS) for MySQL, Amazon RDS for MariaDB 및 Amazon Aurora MySQL 호환 버전에서 보호되는 객체는 다음과 같습니다.

• 한 번에 한 세션에서만 읽거나 쓸 수 있는 뮤텍스가 포함된 binlog 소스 인스턴스의 활성 바이너리 로그 파일
• 데이터 제어 언어(DCL) 또는 데이터 정의 언어(DDL) 문 쓰기에 대해 보호되는 데이터 사전
• 한 번에 한 세션에서만 읽거나 쓸 수 있는 뮤텍스가 포함된 적응형 해시 인덱스
• 한 세션에서만 캐시에 테이블을 추가하거나 제거할 수 있는 오픈 테이블 캐시
• 한 번에 한 세션만 메모리의 블록 내용을 수정할 수 있는 InnoDB 버퍼 풀의 각 데이터베이스 블록

해결 방법

DB 인스턴스에 워크로드를 관리하기 위한 충분한 CPU 리소스가 있는지 확인

SYNCH 이벤트를 기다리는 세션 수가 많으면 CPU 사용량이 많아집니다. 100% 사용량에서는 대기 세션 수가 증가합니다. 이 문제를 해결하려면 추가 워크로드를 처리할 CPU가 충분하도록 ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)DB 인스턴스의 크기를 늘리십시오[.

SYNCH 이벤트는 일반적으로 오래 지속되지 않기 때문에 CPUUtilization Amazon CloudWatch 지표에 피크 사용량이 올바르게 표시되지 않을 수 있습니다. 이 지표의 세분성은 60초에 불과합니다. 피크 사용량을 확인하려면 Amazon RDS 콘솔의 향상된 모니터링에서 1초 단위 세분성 카운터를 사용하십시오.

MySQL 뮤텍스를 늘리거나 대기 배열 잠그기

MySQL은 내부 데이터 구조를 사용하여 기본 배열 크기 1인 스레드를 조정합니다. 이 구성은 단일 CPU 시스템에서 작동하지만 여러 CPU가 있는 시스템에서는 문제가 발생할 수 있습니다. 워크로드에 대기 스레드가 많은 경우 배열 크기를 증가시킵니다. CPU 수와 같거나 더 많도록 MySQL innodb_sync_array_size 파라미터를 수정합니다. 자세한 내용은 MySQL 웹사이트에서 innodb_sync_array_size를 참조하십시오.

참고: MySQL은 데이터베이스 시작 시에만 innodb_sync_array_size 파라미터를 사용합니다.

동시성 감소

일반적으로 병렬 처리는 처리량을 개선합니다. 그러나 많은 수의 세션에서 동일하거나 유사한 활동을 실행하는 경우 해당 세션에는 동일한 보호 객체에 대한 액세스 권한이 있어야 합니다. 세션 수가 많을수록 대기 시 더 많은 CPU를 사용하게 됩니다.

이 문제를 해결하려면 시간이 지남에 따라 활동을 분산하거나 순차적으로 예약하십시오. 다중 행 삽입과 같은 여러 작업을 단일 명령문으로 묶을 수도 있습니다.

대기 이벤트를 기반으로 문제 해결

수신한 대기 이벤트를 기반으로 다음과 같은 문제 해결 조치를 수행하십시오.

synch/rwlock/innodb/dict sys RW lock 또는 synch/rwlock/innodb/dict_operation_lock

이러한 이벤트는 많은 수의 동시 DCL 또는 DDL을 동시에 호출할 때 발생합니다. 이러한 문제를 해결하려면 정기적인 애플리케이션 활동 중에 애플리케이션의 DDL에 대한 의존도를 줄이십시오.

synch/cond/sql/MDL_context::COND_wait_status

이 이벤트는 Select를 비롯한 많은 SQL이 DCL 또는 DDL이 수정 중인 테이블에 액세스할 때 발생합니다. 이 문제를 해결하려면 정기적인 애플리케이션 활동 중에 트래픽이 많은 테이블에서 DDL 문을 실행하지 마십시오.

synch/mutex/sql/LOCK_open 또는 synch/mutex/sql/LOCK_table_cache

이러한 이벤트는 세션에서 연 테이블 수가 테이블 정의 캐시 또는 테이블 오픈 캐시의 크기를 초과할 때 발생합니다. 이 문제를 해결하려면 캐시 크기를 증가시키십시오. 자세한 내용은 MySQL 웹사이트에서 10.4.3.1 MySQL이 테이블을 열고 닫는 방법을 참조하십시오.

synch/mutex/sql/LOG

이 이벤트는 현재 로깅 방법에서는 지원할 수 없는 많은 수의 명령문을 데이터베이스에서 실행할 때 발생합니다. TABLE 출력 방법을 사용하는 경우 FILE을 대신 사용하십시오. 일반 로그를 사용하는 경우 Aurora의 고급 감사를 대신 사용하십시오. long_query_time 파라미터를 0 또는 1보다 작은 값으로 설정한 경우에는 값을 증가시키십시오.

synch/mutex/innodb/buf_pool_mutex, synch/mutex/innodb/aurora_lock_thread_slot_futex 또는 synch/rwlock/innodb/index_tree_rw_lock

이러한 이벤트는 많은 수의 유사한 데이터 조작 언어(DML) 명령문이 동일한 데이터베이스 객체에 동시에 액세스할 때 발생합니다. 이 문제를 해결하려면 다중 행 명령문과 파티션을 사용하여 워크로드를 여러 데이터베이스 객체에 분산시키십시오.

synch/mutex/innodb/aurora_lock_thread_slot_futex

이 이벤트는 한 세션에서 업데이트를 위해 행을 잠근 후 다른 세션에서 해당 행을 업데이트하려고 할 때 발생합니다. 수신한 다른 대기 이벤트를 기반으로 이 문제를 해결하십시오. 이 대기 이벤트의 원인이 되는 SQL 문을 찾아 응답하거나 차단 세션을 찾아 응답하십시오.

synch/cond/sql/MYSQL_BIN_LOG::COND_done, synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit 또는 synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log

이러한 이벤트는 바이너리 로깅을 활성화한 경우 커밋 처리량, 커밋 트랜잭션 또는 binlog를 읽는 복제본이 많을 때 발생합니다. 이 문제를 해결하려면 다중 행 명령문을 사용하거나 여러 명령문을 단일 트랜잭션으로 그룹화하십시오.

Aurora MySQL 호환 대기 이벤트에 대한 자세한 내용은 대기 이벤트가 있는 Aurora MySQL 조정 및 Aurora MySQL 대기 이벤트를 참조하십시오.

8.0 이상과 호환되는 메이저 버전으로 데이터베이스를 업그레이드하는 것이 좋습니다. 가능하면 다중 행 명령문을 사용하거나 여러 명령문을 단일 트랜잭션으로 그룹화하십시오. Aurora에서는 바이너리 로그 복제 대신 Aurora Global Database를 사용하거나 aurora_binlog 파라미터를 사용하십시오.

관련 정보

Amazon RDS의 Performance Insights를 통한 DB 로드 모니터링

Amazon RDS의 파라미터 그룹