# cpu
`cpu` 대기 이벤트는 스레드가 CPU에서 활성 상태이거나 CPU에 대해 대기 중일 때 발생합니다.
**Topics**
+ [지원되는 엔진 버전](#ams-waits.cpu.context.supported)
+ [컨텍스트](#ams-waits.cpu.context)
+ [대기 증가의 가능한 원인](#ams-waits.cpu.causes)
+ [작업](#ams-waits.cpu.actions)
## 지원되는 엔진 버전
이 대기 이벤트 정보는 다음 엔진 버전에서 지원됩니다.
+ Aurora MySQL 버전 2 및 3
## 컨텍스트
모든 vCPU의 경우 연결은 이 CPU에서 작업을 실행할 수 있습니다. 경우에 따라 실행할 준비가 된 활성 연결 수가 vCPU 수보다 많을 수 있습니다. 이러한 불균형으로 인해 CPU 리소스에 대해 대기 중인 연결이 발생합니다. 활성 연결 수가 vCPU 수보다 일관되게 높게 유지되면 해당 인스턴스에 CPU 경합이 발생합니다. 경합으로 인해 `cpu` 대기 이벤트가 발생합니다.
**참고**
CPU의 성능 개선 도우미 지표는 `DBLoadCPU`입니다. `DBLoadCPU`의 값은 CloudWatch 지표 `CPUUtilization`의 값과 다를 수 있습니다. 후자의 지표는 데이터베이스 인스턴스에 대한 HyperVisor에서 수집됩니다.
성능 개선 도우미 OS 지표는 CPU 사용률에 대한 자세한 정보를 제공합니다. 예를 들어 다음 지표가 표시될 수 있습니다.
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
성능 개선 도우미는 데이터베이스 엔진의 CPU 사용량을 `os.cpuUtilization.nice.avg`와 같이 보고합니다.
## 대기 증가의 가능한 원인
이 이벤트가 정상 상태보다 많이 발생하여 성능 문제를 나타낼 수 있는 경우 일반적인 원인은 다음과 같습니다.
+ 분석 쿼리
+ 많은 동시 트랜잭션 수
+ 장기 실행 트랜잭션
+ 연결 수의 급격한 증가를 *로그인 스톰(login storm)*이라고 함
+ 컨텍스트 전환 증가
## 작업
`cpu` 대기 이벤트가 데이터베이스 활동을 지배하는 경우 반드시 성능 문제를 나타내지는 않습니다. 성능이 저하되는 경우만 이 이벤트에 응답하세요.
CPU 사용률 증가의 원인에 따라 다음 전략을 고려하세요.
+ 호스트의 CPU 용량을 늘리세요. 이 접근법은 일반적으로 일시적인 구제만 해당합니다.
+ 잠재적인 최적화를 위해 상위 쿼리를 식별하세요.
+ 해당하는 경우 일부 읽기 전용 워크로드를 리더 노드로 리디렉션하세요.
**Topics**
+ [문제를 일으키는 세션 또는 쿼리 식별](#ams-waits.cpu.actions.az-vpc-subnet)
+ [높은 CPU 워크로드 분석 및 최적화](#ams-waits.cpu.actions.db-instance-class)
### 문제를 일으키는 세션 또는 쿼리 식별
세션과 쿼리를 찾으려면 CPU 로드가 가장 높은 SQL 문에 대한 성능 개선 도우미의 **상위 SQL(Top SQL)** 테이블을 참조하세요. 자세한 내용은 [성능 개선 도우미 대시보드를 사용한 지표 분석](USER_PerfInsights.UsingDashboard.md) 섹션을 참조하세요.
일반적으로 하나 또는 두 개의 SQL 문은 대부분의 CPU 사이클을 사용합니다. 이러한 명령문에 집중하세요. DB 인스턴스에 평균 활성 세션(AAS)이 3.1인 DB 로드가 있는 vCPU 2개가 있고 모두 CPU 상태에 있다고 가정합니다. 이 경우 인스턴스는 CPU 바인딩입니다. 다음과 같은 전략을 생각해 보세요.
+ vCPU가 더 많은 대규모 인스턴스 클래스로 업그레이드하세요.
+ CPU 부하가 낮도록 쿼리를 튜닝하세요.
이 예에서는 최상위 SQL 쿼리에 1.5 AAS의 DB 로드가 있고 모두 CPU 상태입니다. 다른 SQL 문은 CPU 상태의 로드가 0.1입니다. 이 예에서는 로드가 가장 낮은 SQL 문을 중지한 경우 데이터베이스 로드가 크게 줄어들지 않습니다. 그러나 두 개의 로드가 높은 쿼리를 효율적으로 두 배로 최적화하면 CPU 병목 현상을 없앨 수 있습니다. 1.5 AAS의 CPU 로드를 50% 줄이면 각 명령문에 대한 AAS가 0.75로 감소합니다. CPU에 사용된 총 DB 로드는 이제 1.6 AAS입니다. 이 값은 최대 vCPU 라인인 2.0 미만입니다.
성능 개선 도우미를 통한 문제 해결의 개요는 블로그 게시물, [성능 개선 도우미를 통해 Amazon Aurora MySQL 워크로드 분석](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)을 참조하세요. 또한 AWS 지원 문서, [Amazon RDS for MySQL 인스턴스에서 높은 CPU 사용률 문제를 해결하려면 어떻게 해야 하나요?](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/)를 참조하세요.
### 높은 CPU 워크로드 분석 및 최적화
CPU 사용량을 늘리는 하나 이상의 쿼리를 식별한 후 이를 최적화하거나 연결을 종료할 수 있습니다. 다음 예에서는 연결을 종료하는 방법을 보여줍니다.
```
CALL mysql.rds_kill(processID);
```
자세한 내용은 [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) 섹션을 참조하세요.
세션을 종료하면 해당 작업은 긴 롤백을 트리거할 수 있습니다.
#### 쿼리 최적화 지침 준수
쿼리를 최적화하려면 다음 지침을 고려하세요.
+ `EXPLAIN` 문을 실행하세요.
이 명령은 쿼리 실행과 관련된 개별 단계를 보여줍니다. 자세한 내용은 MySQL 설명서의 [EXPLAIN으로 쿼리 최적화](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html)를 참조하세요.
+ `SHOW PROFILE` 문을 실행하세요.
이 명령문을 사용하여 현재 세션 도중에 실행되는 명령문의 리소스 사용량을 나타내는 프로필 세부 정보를 검토할 수 있습니다. 자세한 내용은 MySQL 설명서의 [REPAIR PROFILE 문](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html)을 참조하세요.
+ `ANALYZE TABLE` 문을 실행하세요.
이 명령문을 사용하여 CPU 사용량이 높은 쿼리에서 액세스한 테이블의 인덱스 통계를 새로 고칠 수 있습니다. 명령문을 분석하면 최적화 프로그램이 적절한 실행 계획을 선택할 수 있도록 도울 수 있습니다. 자세한 내용은 MySQL 설명서의 [ANALYZE TABLE 문](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html)을 참조하세요.
#### CPU 사용량 향상을 위한 지침 준수
데이터베이스 인스턴스의 CPU 사용을 개선하려면 다음 지침을 따르세요.
+ 모든 쿼리가 적절한 인덱스를 사용하고 있는지 확인합니다.
+ Aurora 병렬 쿼리를 사용할 수 있는지 확인합니다. 이 기술을 사용하여 기능 처리, 행 필터링 및 `WHERE` 절의 열 프로젝션을 낮추어 헤드 노드에서 CPU 사용량을 줄일 수 있습니다.
+ 초당 SQL 실행 수가 예상 임계값을 충족하는지 확인합니다.
+ 인덱스 유지 관리 또는 새 인덱스 생성이 프로덕션 워크로드에 필요한 CPU 사이클을 차지하는지 확인합니다. 피크 활동 시간 이외의 시간에 유지 관리 활동을 예약합니다.
+ 파티셔닝을 사용하여 쿼리 데이터 세트를 줄일 수 있는지 확인합니다. 자세한 내용은 블로그 게시물, [통합 워크로드를 위해 MySQL과 호환되는 Amazon Aurora를 계획하고 최적화하는 방법](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/)을 참조하세요.
#### 연결 스톰 확인
`DBLoadCPU` 지표는 그다지 높지 않지만 `CPUUtilization` 지표가 높은 경우 CPU 사용률이 높은 원인은 데이터베이스 엔진 외부에 있습니다. 전형적인 예는 연결 스톰입니다.
다음 조건이 true인지 확인합니다.
+ 두 성능 개선 도우미, `CPUUtilization` 지표 및 Amazon CloudWatch `DatabaseConnections` 지표 모두에서 증가했습니다.
+ CPU의 스레드 수가 vCPU 수보다 큽니다.
위의 조건이 true이면 데이터베이스 연결 수를 줄이는 것이 좋습니다. 예를 들어 RDS Proxy와 같은 연결 풀을 사용할 수 있습니다. 효과적인 연결 관리 및 크기 조정에 대한 모범 사례를 알아보려면 [연결 관리를 위한 Amazon Aurora MySQL DBA 핸드북](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf) 백서를 참조하세요.