io/table/sql/handler - Amazon Aurora
지원되는 엔진 버전컨텍스트대기 증가의 가능한 원인작업

io/table/sql/handler

io/table/sql/handler 이벤트는 작업을 스토리지 엔진에 작업이 위임했을 때 발생합니다.

지원되는 엔진 버전

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

  • Aurora MySQL 버전 3: 3.01.0 및 3.01.1

  • Aurora MySQL 버전 2

컨텍스트

io/table 이벤트는 테이블에 대한 액세스를 기다리고 있음을 나타냅니다. 이 이벤트는 데이터가 버퍼 풀에 캐시되는지 디스크에서 액세스되는지 관계없이 발생합니다. io/table/sql/handler 이벤트는 워크로드 활동의 증가를 나타냅니다.

처리기(handler)는 특정 유형의 데이터를 전문화하거나 특정 특수 작업에 중점을 둔 루틴입니다. 예를 들어 이벤트 처리기는 운영 체제 또는 사용자 인터페이스에서 이벤트와 신호를 수신하고 다이제스트합니다. 메모리 처리기는 메모리와 관련된 작업을 수행합니다. 파일 입력 처리기는 컨텍스트에 따라 파일 입력을 수신하고 데이터에 대한 특수 작업을 수행하는 기능입니다.

performance_schema.events_waits_current와 같은 보기는 실제 대기가 잠금과 같은 중첩된 대기 이벤트인 경우 io/table/sql/handler를 보여주는 경우가 많습니다. 실제 대기 시간이 io/table/sql/handler가 아닌 경우 성능 개선 도우미는 중첩된 대기 이벤트를 보고합니다. 성능 개선 도우미가 io/table/sql/handler를 보고하는 경우는 숨겨진 중첩 대기 이벤트가 아니라 I/O 요청의 InnoDB 처리를 나타냅니다. 자세한 내용은 MySQL 참조 설명서에서 성능 스키마 원자 및 분자 이벤트를 참조하세요.

참고

하지만 Aurora MySQL 3.01.0 및 3.01.1 버전에서 synch/mutex/innodb/aurora_lock_thread_slot_futex는 io/table/sql/handler로 보고됩니다.

io/table/sql/handler 이벤트는 io/aurora_redo_log_flush 및 io/file/innodb/innodb_data_file과 같은 I/O 대기를 통해 상위 대기 이벤트에 나타나는 경우가 많습니다.

대기 증가의 가능한 원인

성능 개선 도우미에서 io/table/sql/handler 이벤트의 급격한 스파이크는 워크로드 활동의 증가를 나타냅니다. 활동 증가는 I/O 증가를 의미합니다.

성능 개선 도우미는 중첩 이벤트 ID를 필터링하고 기본 중첩 이벤트가 잠금 대기인 경우 io/table/sql/handler 대기를 보고하지 않습니다. 예를 들어 근본 원인 이벤트가 synch/mutex/innodb/aurora_lock_thread_slot_futex인 경우 성능 개선 도우미는 이 대기를 io/table/sql/handler가 아닌 상위 대기 이벤트에 표시합니다.

performance_schema.events_waits_current와 같은 보기에서 io/table/sql/handler의 대기는 실제 대기가 잠금과 같은 중첩된 대기 이벤트인 경우 나타나는 경우가 많습니다. 실제 대기가 io/table/sql/handler와 다른 경우 성능 개선 도우미는 중첩된 대기를 조회하고 io/table/sql/handler가 아닌 실제 대기를 보고합니다. 성능 개선 도우미가 io/table/sql/handler를 보고하는 경우 실제 대기는 숨겨진 중첩 대기 이벤트가 아닌 io/table/sql/handler입니다. 자세한 내용은 MySQL 5.7 참조 설명서에서 성능 스키마 원자 및 분자 이벤트를 참조하세요.

참고

하지만 Aurora MySQL 3.01.0 및 3.01.1 버전에서 synch/mutex/innodb/aurora_lock_thread_slot_futex는 io/table/sql/handler로 보고됩니다.

작업

이 대기 이벤트가 데이터베이스 활동을 지배하는 경우 반드시 성능 문제를 나타내는 것은 아닙니다. 데이터베이스가 활성 상태일 때 대기 이벤트는 항상 맨 위에 있습니다. 성능이 저하될 때만 조치해야 합니다.

표시되는 다른 대기 이벤트에 따라 다른 작업을 권장합니다.

이벤트를 일으키는 세션 및 쿼리 식별

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

높은 로드에 책임이 있는 SQL 쿼리를 찾으려면

  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 탐색 창에서 Performance Insights(성능 개선 도우미)를 선택합니다.

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

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

  5. 페이지 하단에서 상위 SQL(Top SQL)을 선택합니다.

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

성능 개선 도우미를 통한 문제 해결의 개요는 블로그 게시물, 성능 개선 도우미를 통해 Amazon Aurora MySQL 워크로드 분석을 참조하세요.

성능 개선 도우미 카운터 지표를 통해 상관관계 확인

Innodb_rows_changed와 같은 성능 개선 도우미 카운터 지표를 확인합니다. 카운터 지표가 io/table/sql/handler와 상호 연관되어 있는 경우 다음 단계를 따르세요.

  1. 성능 개선 도우미에서 io/table/sql/handler 상위 대기 이벤트에 해당하는 SQL 문을 찾습니다. 가능한 경우 더 적은 수의 행을 반환하도록 이 명령문을 최적화합니다.

  2. schema_table_statistics 및 x$schema_table_statistics 보기에서 상위 테이블을 검색합니다. 이러한 보기는 테이블당 소요된 시간을 보여줍니다. 자세한 내용은 MySQL 참조 설명서에서 schema_table_statistics 및 x$schema_table_statistics 보기를 참조하세요.

    기본적으로 행은 총 대기 시간의 내림차순으로 정렬됩니다. 경합이 가장 많은 테이블이 먼저 표시됩니다. 출력은 읽기, 쓰기, 가져오기, 삽입, 업데이트 또는 삭제에 소요되는 시간 여부를 나타냅니다. 다음 예는 Aurora MySQL 2.09.1 인스턴스에서 실행되었습니다.

    mysql> select * from sys.schema_table_statistics limit 1\G

*************************** 1. row ***************************
     table_schema: read_only_db
       table_name: sbtest41
    total_latency: 54.11 m
     rows_fetched: 6001557
    fetch_latency: 39.14 m
    rows_inserted: 14833
   insert_latency: 5.78 m
     rows_updated: 30470
   update_latency: 5.39 m
     rows_deleted: 14833
   delete_latency: 3.81 m
 io_read_requests: NULL
          io_read: NULL
  io_read_latency: NULL
io_write_requests: NULL
         io_write: NULL
 io_write_latency: NULL
 io_misc_requests: NULL
  io_misc_latency: NULL
1 row in set (0.11 sec)

다른 상호 연관된 대기 이벤트 확인

synch/sxlock/innodb/btr_search_latch 및 io/table/sql/handler가 DB 로드 이상에 가장 많이 기여하는 경우 innodb_adaptive_hash_index 변수가 활성화되어 있는지 확인합니다. 그렇다면 innodb_adaptive_hash_index_parts 파라미터 값을 늘리는 것이 좋습니다.

Adaptive Hash Index가 꺼져 있는 경우 켜는 것이 좋습니다. MySQL Adaptive Hash Index에 대한 자세한 내용은 다음 리소스를 참조하세요.

참고

Adaptive Hash Index는 Aurora 리더 DB 인스턴스에서 지원되지 않습니다.

경우에 따라 synch/sxlock/innodb/btr_search_latch 및 io/table/sql/handler가 지배적이면 리더 인스턴스에서 성능이 저하될 수 있습니다. 그렇다면 워크로드를 일시적으로 작성기 DB 인스턴스로 리디렉션하고 Adaptive Hash Index를 켜는 것이 좋습니다.