# synch/sxlock/innodb/hash\_table\_locks
<a name="ams-waits.sx-lock-hash-table-locks"></a>

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

**Topics**
+ [지원되는 엔진 버전](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [컨텍스트](#ams-waits.sx-lock-hash-table-locks.context)
+ [대기 증가의 가능한 원인](#ams-waits.sx-lock-hash-table-locks.causes)
+ [작업](#ams-waits.sx-lock-hash-table-locks.actions)

## 지원되는 엔진 버전
<a name="ams-waits.sx-lock-hash-table-locks.context.supported"></a>

이 대기 이벤트 정보는 다음 버전에서 지원됩니다.
+ Aurora MySQL 버전 2 및 3

## 컨텍스트
<a name="ams-waits.sx-lock-hash-table-locks.context"></a>

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

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

자세한 내용은 MySQL 설명서의 [버퍼 풀](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html)을 참조하세요.

## 대기 증가의 가능한 원인
<a name="ams-waits.sx-lock-hash-table-locks.causes"></a>

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

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

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

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

## 작업
<a name="ams-waits.sx-lock-hash-table-locks.actions"></a>

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

**Topics**
+ [버퍼 풀의 크기 늘리기](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [데이터 액세스 패턴 개선](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [전체 테이블 스캔 감소 또는 방지](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [오류 로그에서 페이지 손상 확인](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)

### 버퍼 풀의 크기 늘리기
<a name="ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size"></a>

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

### 데이터 액세스 패턴 개선
<a name="ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns"></a>

이 대기 및 실행 계획의 영향을 받는 쿼리를 확인합니다. 데이터 액세스 패턴을 개선하는 것이 좋습니다. 예를 들어 [mysqli\_result::fetch\_array](https://www.php.net/manual/en/mysqli-result.fetch-array.php)를 사용 중인 경우 배열 가져오기 크기를 늘릴 수 있습니다.

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

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

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

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

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

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

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

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

성능 개선 도우미를 통한 문제 해결에 대한 유용한 개요는 AWS 데이터베이스 블로그 게시물, [성능 개선 도우미를 통해 Amazon Aurora MySQL 워크로드 분석](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)을 참조하세요.

### 전체 테이블 스캔 감소 또는 방지
<a name="ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans"></a>

워크로드를 모니터링하여 전체 테이블 스캔이 실행되고 있는지 확인하고, 있는 경우 워크로드를 줄이거나 방지할 수 있습니다. 예를 들어 `Handler_read_rnd_next`와 같은 상태 변수를 모니터링할 수 있습니다. 자세한 내용은 MySQL 설명서에서 [서버 상태 변수](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next)를 참조하세요.

### 오류 로그에서 페이지 손상 확인
<a name="ams-waits.sx-lock-hash-table-locks.actions.check-error-logs"></a>

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