내 MySQL DB 인스턴스에 성능 개선 도우미의 SYNCH 대기 이벤트에서 대기하는 활성 세션 수가 많이 표시되는 이유는 무엇입니까?

최종 업데이트 날짜: 2020년 12월 14일

RDS MySQL, RDS MariaDB 또는 Amazon Aurora MySQL 인스턴스가 있고 성능 개선 도우미를 활성화했습니다. 내 DB 인스턴스에 동기화(SYNCH) 대기 이벤트에서 대기하는 AAS(평균 활성 세션) 수가 많이 표시됩니다. SYNCH 이벤트로 인해 쿼리 속도가 느려지는 이유는 무엇이며 DB 인스턴스의 성능을 개선하려면 어떻게 해야 합니까?

간략한 설명

성능 개선 도우미에 MySQL SYNCH 대기 이벤트가 표시되면 데이터베이스의 많은 세션이 동일한 보호 객체 또는 메모리 구조에 액세스하려고 시도하고 있음을 의미합니다. MySQL의 보호 객체에는 다음이 포함됩니다.

  • binlog 소스 인스턴스의 활성 바이너리 로그 파일 - 한 세션만 언제든지 읽거나 쓸 수 있도록 허용하는 뮤텍스를 포함합니다.
  • 데이터 딕셔너리 - 일반적으로 DCL(데이터 제어 언어) 또는 DDL(데이터 정의 언어) 문에 의해 발생하며, 쓰기용입니다.
  • 적응형 해시 인덱스 - 한 세션만 언제든지 읽거나 쓸 수 있도록 허용하는 뮤텍스를 포함합니다.
  • 열린 테이블 캐시 - 하나의 세션만 캐시에서 테이블을 추가하거나 제거할 수 있습니다.
  • InnoDB 버퍼 풀 내부의 각 단일 데이터베이스 블록 - 한 번에 하나의 세션만 메모리에 있는 블록의 콘텐츠를 수정할 수 있습니다.

참고: SQL 쿼리에서 병렬 처리를 늘리기 위해 수행할 수 있는 여러 단계가 있습니다. 경우에 따라, 애플리케이션의 아키텍처와 애플리케이션이 데이터베이스를 사용하여 이러한 문제를 해결하는 방법을 자세히 살펴봐야 합니다.

해결 방법

DB 인스턴스에 워크로드를 처리할 수 있는 충분한 양의 CPU 리소스 확보

SYNCH 이벤트에서 대기 중인 세션 수가 많으면 CPU 사용량이 많아집니다. 사용량이 100%에 도달하면 대기 중인 세션 수가 증가합니다. 문제 해결 시, DB 인스턴스의 크기를 늘려 추가 워크로드를 처리할 수 있도록 충분한 양의 CPU를 확보합니다.

이러한 이벤트는 일반적으로 단기성이기 때문에 Amazon CloudWatch CPU 사용률 지표에 최대 사용량이 올바르게 표시되지 않을 수 있습니다. 이를 확인하는 가장 좋은 방법은 RDS Enhanced Monitoring에서 1초 CPU 카운터를 사용하는 것입니다. 이런 카운터는 더욱 세밀하고 자세합니다.

MySQL의 뮤텍스/잠금 대기 배열 증가

MySQL은 내부 데이터 구조를 사용하여 스레드를 조정합니다. 이 배열은 기본적으로 하나의 크기를 갖습니다. 이는 단일 CPU 시스템에 적합하지만 여러 CPU가 있는 시스템에서는 문제를 일으킬 수 있습니다. 워크로드에 대기 중인 스레드 수가 많은 경우 배열 크기를 늘립니다. MySQL 파라미터 innodb_sync_array_size를 CPU의 양(또는 그 이상(최대 1024))으로 설정합니다.

참고: innodb_sync_array_size 파라미터는 데이터베이스 시작 시에만 적용됩니다.

동시성 감소

일반적으로 병렬 처리는 처리량을 향상시키는 데 도움이 됩니다. 그러나 많은 수의 세션이 동일하거나 유사한 작업을 수행하려고 할 때 세션은 동일한 보호 객체에 액세스해야 합니다. 세션 수가 많을수록 대기하는 동안 더 많은 CPU를 사용하게 됩니다.

시간 경과에 따라 이러한 작업을 분산하거나 연속으로 일정을 예약합니다. 여러 작업을 다중 행 삽입과 같은 단일 문으로 묶을 수도 있습니다.

특정 대기 이벤트 검사

아래의 예제 해결 방법을 사용하여 특정 대기 이벤트 문제를 해결하세요.

  • synch/rwlock/innodb/dict sys RW lock 또는 synch/rwlock/innodb/dict_operation_lock - 이는 DDL의 동시 DCL이 한번에 많은 수로 트리거됨을 나타냅니다. 일반 애플리케이션 작업 중에 DDL 사용에 대한 애플리케이션의 종속성을 줄입니다.
  • synch/cond/sql/MDL_context::COND_wait_status - 이는 많은 수의 SQL(선택 포함)이 DCL 또는 DDL이 수정 중인 테이블에 액세스하려 시도하고 있음을 나타냅니다. 일반 애플리케이션 작업 중에는 트래픽이 많은 테이블에 DDL 문을 실행하지 마세요.
  • 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 수가 많거나 이런 현상이 동시에 일어났을 수 있습니다. 데이터베이스를 5.7 이상과 호환되는 메이저 버전으로 업그레이드하는 것이 좋습니다. 또한 다중 행 문을 사용하거나 여러 개의 문을 단일 트랜잭션으로 묶습니다. Aurora에서는 바이너리 로그 복제 대신 글로벌 데이터베이스를 사용하거나 aurora_binlog_* 파라미터를 사용합니다.
  • synch/mutex/sql/LOCK_open 또는 synch/mutex/sql/LOCK_table_cache - 세션이 여는 테이블의 수가 테이블 정의 캐시 또는 테이블 열기 캐시의 크기를 초과함을 나타냅니다. 해당 캐시의 크기를 늘립니다.
  • synch/mutex/sql/LOG - 데이터베이스가 많은 수의 문을 실행 중일 수 있으며 현재 로깅 메서드가 따라갈 수 없습니다. TABLE 출력 메서드를 사용하는 경우 대신 FILE을 사용해보세요. 일반 로그를 사용하는 경우 대신 Aurora 고급 감사를 사용해보세요. long_query_time 파라미터에 대해 0 또는 1보다 작은 값을 사용하는 경우 값을 늘려보세요.
  • synch/mutex/innodb/buf_pool_mutex or synch/mutex/innodb/aurora_lock_thread_slot_futex 또는 synch/rwlock/innodb/index_tree_rw_lock - 동일한 데이터베이스 객체에 동시에 액세스하는 유사한 DML이 많이 있습니다. 다중 행 문을 사용해보세요. 또한 워크로드를 다른 데이터베이스 객체에 걸쳐 분산합니다. 이 작업을 수행하는 한 가지 방법은 파티셔닝을 사용하는 것입니다.

이 문서가 도움이 되었나요?


결제 또는 기술 지원이 필요합니까?