RDS for SQL Server 인스턴스에서 높은 CPU 사용률 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

CPU 사용률이 증가하는 일반적인 이유는 다음과 같습니다.

• 사용자가 과중한 워크로드, 여러 개의 동시 쿼리 또는 장기 실행 트랜잭션을 시작
• 워크로드에 프로비저닝이 부족한 인스턴스 클래스 사용
• 오래된 통계 및 인덱스 단편화 또는 누락된 인덱스
• 개선 범위가 포함된 쿼리
• 차단 및 교착 상태
• 병렬 처리
• 쿼리 컴파일 및 재컴파일
• 파라미터 스니핑
• 스레드 소진

Amazon RDS for SQL Server 인스턴스의 CPU 사용량 소스를 확인하려면 다음과 같은 도구를 사용합니다.

• Amazon RDS용 Amazon CloudWatch 지표
• 향상된 모니터링
• 성능 개선 도우미
• SQL Server 네이티브 툴

소스를 식별한 후 워크로드를 분석하고 최적화하여 CPU 사용량을 줄일 수 있습니다.

해결 방법

Amazon RDS용 Amazon CloudWatch 지표

CloudWatch 지표를 사용하여 장기간에 걸쳐 CPU 패턴을 식별할 수 있습니다. WriteIOPs, ReadIOPs, ReadThroughput 및 WriteThroughput 그래프를 CPU 사용률과 비교하여 워크로드에서 CPU를 많이 사용하는 시점을 알아냅니다. 자세한 내용은 Amazon CloudWatch metrics for Amazon RDS를 참조하십시오.

t2 또는 t3 인스턴스 클래스의 인스턴스를 사용하는 경우 인스턴스에 프로비저닝이 부족한지 확인합니다. CPU 크레딧 밸런스가 지속적으로 감소하고 CPU 크레딧 사용량이 지속적으로 증가한다면 CPU 코어로는 워크로드에 충분하지 않은 것입니다.

시간대를 식별한 후에 DB 인스턴스에 연결된 Enhanced Monitoring 데이터를 검토할 수 있습니다. 1, 5, 10, 15, 30, 60초 간격으로 데이터를 수집하도록 Enhanced Monitoring을 설정할 수 있습니다. 이렇게 하면 CloudWatch보다 더욱 짧은 간격으로 데이터를 수집할 수 있습니다.

향상된 모니터링

향상된 모니터링을 설정한 경우 이를 사용하여 DB 인스턴스에서 실행 중인 OS를 모니터링할 수 있습니다. 향상된 모니터링을 사용하여 CPU 사용률을 확인하려면 다음과 같이 하십시오.

1. RDS 콘솔에서 데이터베이스를 선택한 다음 데이터베이스를 선택합니다.
2. 모니터링 탭에서 OS 프로세스 목록을 모니터링 드롭다운 메뉴에서 선택합니다. 높은 CPU가 OS, RDS 프로세스, SQL Server 프로세스 또는 SQL 에이전트 프로세스에 의해 구동되는지 확인합니다. 또한 이러한 프로세스에서 사용 중인 CPU의 비율과 메모리 비율을 확인할 수 있습니다.
3. 향상된 모니터링 드롭다운 목록에서 지표를 선택하여 성능 모니터 데이터를 확인합니다. 이러한 지표에는 CPU 유휴, 커널 및 사용자가 있습니다. 이러한 지표는 CPU가 대부분의 시간을 유휴 상태인지, 커널을 실행하는지, 사용자 프로세스를 실행하고 있는지를 알려줍니다.
4. 그래프 관리를 선택하여 다른 지표를 볼 수 있습니다. 그런 다음 I/O 및 디스크 스루풋과 관련된 지표를 선택할 수 있습니다. 이러한 지표에는 읽기/초, 쓰기/초, 읽기 KB/s 및 쓰기 KB/s가 있습니다. 여유 메모리, SQL Server 메모리 및 총 메모리를 비롯한 메모리 관련 파라미터도 볼 수 있습니다. 이러한 지표는 CPU가 리소스를 기다리는 데 많은 시간을 소비하는 경우 CPU 사용률이 높을 수 있으므로 유용합니다.

자세한 내용은 RDS 콘솔에서 OS 지표 보기를 참조하십시오.

성능 개선 도우미

Amazon RDS 성능 개선 도우미를 사용하여 데이터베이스 부하를 담당하는 쿼리를 식별할 수 있습니다. 이렇게 하려면 다음을 수행합니다.

1. 분석하려는 시간대에 해당하는 SQL 탭을 확인하십시오.
2. 시간이 가장 오래 걸리는 쿼리를 식별합니다.
3. 리소스 사용량이 많은 쿼리와 이 기간 동안 관찰된 대기 이벤트를 확인하십시오. 다음은 CPU 사용률이 높을 때 자주 발생하는 대기 이벤트입니다.
   SOS_SCHEDULER_YIELD: 이 대기 시간은 다른 사람이 실행하기 위해 작업자가 산출한 것입니다. 대기 횟수가 많고 대기 시간이 짧음은 일반적으로 CPU에 바인딩된 쿼리를 나타냅니다. 여기서 대기 시간이 길어지면 수율 문제가 발생할 수 있습니다. 대기 시간이 길면 워크로드를 추가로 검토해야 합니다.
   SOS_SCHEDULER_YIELD가 널리 사용되는 대기 유형인 경우 CPU 압력이 문제임을 나타낼 수 있습니다. 워크로드 유형을 검토하고 추가 튜닝을 수행합니다.
   CXPACKET 및 CXCONSUMER: 병렬 처리 관련 대기 이벤트는 일반적으로 문제가 되지 않습니다. 그러나 대기 이벤트가 자주 발생하여 성능에 영향을 미치는 경우에는 쿼리를 검토하고 병렬 처리 비용 임계값에 적합한 값을 설정하십시오. SQL Server가 파라미터 그룹에서 저렴한 병렬 처리 파라미터를 선택하는지 확인하십시오.
   사용 사례에 따라 쿼리 또는 인스턴스 수준에서 MAXDOP(최대 병렬 처리 수준)을 1로 늘릴 수도 있습니다.
   ThreadPool: 이 대기 이벤트는 스레드 고갈을 나타냅니다. 인스턴스 클래스에서 이를 처리할 수 있는 경우 최대 워커 스레드 파라미터를 늘립니다. 스레드를 너무 많이 사용하면 ThreadPool 대기가 발생할 수 있습니다. 과도한 스레드의 원인은 차단, 높은 워크로드 또는 대량의 병렬 쿼리입니다. 또는 최대 워커 스레드 파라미터의 구성이 잘못되면 이러한 대기가 발생할 수 있습니다.
4. 데이터베이스 지표에서 배치 요청, SQL 컴파일 및 SQL 재컴파일을 확인합니다. 쿼리가 즉흥적으로 실행되었음을 나타내는 쿼리의 다회 컴파일 여부를 확인합니다. 또한 쿼리 코드에서 재컴파일이 사용되었음을 나타내는 쿼리의 지정된 배치에 대한 잦은 컴파일 여부를 확인합니다. 이 두 가지 모두 CPU 사용량을 높입니다.

SQL Server 네이티브 툴

CPU 문제 해결을 위한 특정 쿼리: 자세한 내용은 Microsoft 설명서 웹 사이트에서 SQL Server에서 CPU 사용량이 많은 문제 해결을 참조하십시오. CPU를 많이 사용하는 쿼리, 업데이트 통계, 누락된 인덱스 및 파라미터 스니핑에 집중하십시오.

실행 계획에서 성능이 떨어지는 쿼리를 확인하고 추가 조정을 수행합니다. 자세한 내용은 Microsoft 설명서 웹 사이트의 실제 실행 계획 표시를 참조하십시오.

쿼리와 확장 이벤트를 사용하여 과도한 잠금, 차단 및 교착 상태 관련 문제를 해결합니다. 자세한 내용은 Microsoft 설명서 웹 사이트에서 SQL Server 차단 문제 이해 및 해결을 참조하십시오.

참고: RDS for SQL Server에서 확장 이벤트를 구성할 때는 일반적인 XEL 파일 저장 방법을 사용할 수 없습니다. 확장 이벤트 구성 방법에 대한 지침은 Amazon RDS for SQL Server에서 확장 이벤트 설정을 참조하십시오.

SQL Server 보고서를 사용하면 SQL Server에서 기본적으로 사용할 수 있는 성능 보고서를 얻을 수 있습니다. 이 보고서를 사용하여 워크로드를 세밀하게 조정할 수 있습니다. 자세한 내용은 Microsoft 설명서 웹 사이트의 성능 대시보드를 참조하십시오.

---