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

4분 분량
0

Performance Insights를 활성화할 때 내 DB 인스턴스에 동기화(SYNCH) 대기 이벤트에서 대기하는 AAS(평균 활성 세션) 수가 많이 표시됩니다. DB 인스턴스의 성능을 개선하고 싶습니다.

간략한 설명

Performance Insights는 다음 서비스 중 하나에서 활성화됩니다.

  • Amazon Relational Database Service(Amazon RDS) for MySQL.
  • Amazon RDS for MariaDB.
  • Amazon Aurora MySQL-호환 버전.

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

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

해결 방법

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를 사용하게 됩니다.

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

특정 대기 이벤트 검사

다음 예제를 사용하여 특정 대기 이벤트 문제를 해결하세요. Aurora MySQL 대기 이벤트에 대한 자세한 내용은 대기 이벤트를 통한 Aurora MySQL 조정을 참조하세요.

  • 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/mutex/sql/LOCK_open, 또는
    synch/mutex/sql/LOCK_table_cache - 세션이 여는 테이블의 수가 테이블 정의 캐시 또는 테이블 열기 캐시의 크기를 초과함을 나타냅니다. 해당 캐시의 크기를 늘립니다.
  • synch/mutex/sql/LOG - 데이터베이스가 많은 수의 문을 실행 중일 수 있으며 현재 로깅 메서드가 지원할 수 없습니다. TABLE 출력 방법을 사용하는 경우 대신 FILE을 사용해보세요. 일반 로그를 사용하는 경우 대신 Amazon 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 - 바이너리 로깅을 설정했으며 다음 중 하나가 발생할 수 있습니다.

                         - 커밋 처리량이 높습니다.

                         - 많은 수의 트랜잭션이 커밋됩니다.

                         - 복제본이 바이너리 로그를 읽습니다.

                         - 이들의 조합.

데이터베이스를 5.7 이상과 호환되는 메이저 버전으로 업그레이드하는 것이 좋습니다. 또한 다중 행 문을 사용하거나 여러 개의 문을 단일 트랜잭션으로 묶습니다. Amazon Aurora에서는 바이너리 로그 복제 대신 글로벌 데이터베이스를 사용하거나 aurora_binlog 파라미터를 사용합니다.


관련 정보

Amazon RDS 성능 개선 도우미 사용

DB 파라미터 그룹 작업

Aurora MySQL 이벤트

AWS 공식
AWS 공식업데이트됨 일 년 전