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

synch/sxlock/innodb/hash_table_locks

synch/sxlock/innodb/hash_table_locks 이벤트는 버퍼 풀에서 찾을 수 없는 페이지를 스토리지에서 읽어야 할 때 발생합니다.

지원되는 엔진 버전

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

  • Aurora MySQL 버전 2 및 3

컨텍스트

synch/sxlock/innodb/hash_table_locks 이벤트는 워크로드가 버퍼 풀에 저장되지 않은 데이터에 자주 액세스하고 있음을 나타냅니다. 이 대기 이벤트는 버퍼 풀에서 새 페이지 추가 및 이전 데이터 제거와 연결됩니다. 버퍼 풀에 저장된 데이터는 오래된 데이터와 새 데이터를 캐시해야 하므로 오래된 페이지는 새 페이지의 캐싱을 허용하도록 제거됩니다. MySQL은 최소최근사용(LRU) 알고리즘을 사용하여 버퍼 풀에서 페이지를 제거합니다. 워크로드가 버퍼 풀에 로드되지 않은 데이터 또는 버퍼 풀에서 제거된 데이터에 액세스하려고 합니다.

이 대기 이벤트는 워크로드가 디스크의 파일에 있는 데이터에 액세스해야 하거나 블록이 버퍼 풀의 LRU 목록에서 해제되거나 추가될 때 발생합니다. 이러한 작업은 공유 배타 잠금(SX-lock)을 획득하기 위해 대기합니다. 이 SX-lock은 버퍼 풀 액세스 성능을 향상하도록 설계된 메모리의 테이블인 해시 테이블(hash table)을 통한 동기화에 사용됩니다.

자세한 내용은 MySQL 설명서의 버퍼 풀을 참조하세요.

대기 증가의 가능한 원인

synch/sxlock/innodb/hash_table_locks 대기 이벤트가 정상보다 많이 나타나 성능 문제를 나타낼 수 있는 경우 일반적인 원인은 다음과 같습니다.

크기가 작은 버퍼 풀

버퍼 풀의 크기가 너무 작아서 자주 액세스하는 모든 페이지를 메모리에 보관할 수 없습니다.

많은 워크로드

워크로드로 인해 자주 제거되고 버퍼 캐시에서 데이터 페이지가 다시 로드됩니다.

페이지를 읽는 중 오류

버퍼 풀에서 페이지를 읽는 중에 오류가 발생하여 데이터 손상을 나타낼 수 있습니다.

작업

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

버퍼 풀의 크기 늘리기

버퍼 풀의 크기가 워크로드에 맞게 적절한지 확인합니다. 이렇게 하면 버퍼 풀 캐시 적중률을 확인할 수 있습니다. 일반적으로 값이 95% 미만으로 떨어지면 버퍼 풀 크기를 늘리는 것이 좋습니다. 버퍼 풀이 클수록 자주 액세스하는 페이지를 메모리에 더 오래 유지할 수 있습니다. 버퍼 풀의 크기를 늘리려면 innodb_buffer_pool_size 파라미터 값을 수정합니다. 이 파라미터의 기본값은 DB 인스턴스 클래스 크기를 기반으로 합니다. 자세한 내용은 Amazon Aurora MySQL 데이터베이스 구성에 대한 모범 사례를 참조하세요.

데이터 액세스 패턴 개선

이 대기 및 실행 계획의 영향을 받는 쿼리를 확인합니다. 데이터 액세스 패턴을 개선하는 것이 좋습니다. 예를 들어 mysqli_result::fetch_array를 사용 중인 경우 배열 가져오기 크기를 늘릴 수 있습니다.

성능 개선 도우미를 사용하여 synch/sxlock/innodb/hash_table_locks 대기 이벤트를 일으킬 수 있는 쿼리 및 세션을 표시할 수 있습니다.

높은 로드에 책임이 있는 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 쿼리가 나열됩니다. 목록의 맨 위에 있는 쿼리가 가장 큰 책임이 있습니다. 병목 현상을 해결하려면 다음 명령문에 집중하세요.

성능 개선 도우미를 통한 문제 해결에 대한 유용한 개요는 AWS 데이터베이스 블로그 게시물, 성능 개선 도우미를 통해 Amazon Aurora MySQL 워크로드 분석을 참조하세요.

전체 테이블 스캔 감소 또는 방지

워크로드를 모니터링하여 전체 테이블 스캔이 실행되고 있는지 확인하고, 있는 경우 워크로드를 줄이거나 방지할 수 있습니다. 예를 들어 Handler_read_rnd_next와 같은 상태 변수를 모니터링할 수 있습니다. 자세한 내용은 MySQL 설명서에서 서버 상태 변수를 참조하세요.

오류 로그에서 페이지 손상 확인

mysql-error.log에서 문제 발생 시점에 감지된 손상 관련 메시지가 있는지 확인할 수 있습니다. 문제를 해결하기 위해 작업할 수 있는 메시지는 오류 로그에 있습니다. 손상된 것으로 보고된 객체를 다시 작성해야 할 수 있습니다.