높은 CPU 사용률

높은 CPU 사용률은 Amazon DocumentDB로 작업하는 동안 발생할 수 있는 문제 중 하나입니다. 이 섹션에서는 문제를 해결하기 위한 인사이트를 제공합니다.

식별 - 문제 발견

Amazon DocumentDB 인스턴스의 CPU 사용률이 높으면 모든 데이터베이스 작업에서 지연 시간이 증가하여 애플리케이션 속도가 느려집니다. Amazon DocumentDB CPU 사용량이 최적 수준 이상으로 증가하면 쿼리 실행 시간이 증가하고 연결 설정이 더 오래 걸리며 애플리케이션 응답성이 감소합니다. 기본 인스턴스의 CPU 피크는 쓰기 작업이 느리지만 복제본의 피크는 읽기 작업의 지연 시간을 높입니다.

Amazon DocumentDB에서 CPU 사용률이 높은 일반적인 원인은 다음과 같습니다.

• 컬렉션 스캔: 적절한 인덱스가 없는 쿼리는 전체 컬렉션 스캔을 강제로 실행하여 모든 문서를 검사하기 위해 과도한 CPU를 사용합니다.

• 연결 스파이크: 애플리케이션 연결의 갑작스러운 급증으로 인증 및 세션 관리에 필요한 CPU 리소스가 압도됩니다.

• 복잡한 집계: 다단계 작업(정렬, 그룹화, 조인)은 특히 인덱스가 최적화되지 않은 대규모 데이터 세트에서 상당한 CPU를 소비합니다.

• 비효율적인 쿼리: 대규모 결과 집합 및 정규식 작업을 스캔하여 CPU 사용량이 높습니다.

• 쓰기 중심 워크로드: 문서 처리, 인덱스 업데이트 및 트랜잭션 로깅을 통해 CPU 부담을 자주 업데이트하고 대량으로 삽입합니다.

조사 - 지표 수집

Amazon DocumentDB는 Amazon CloudWatch를 통해 모니터링을 제공합니다. Amazon DocumentDB 지표는 클러스터 수준 및 인스턴스 수준 지표로 광범위하게 분류할 수 있습니다. CPU, 메모리 및 연결과 관련된 리소스의 경우 리소스 소비가 인스턴스에 고유하므로 인스턴스 수준 지표를 살펴봅니다. CPU 스파이크를 표시하는 인스턴스(기본 또는 복제본)를 식별하고 스파이크 시간을 기록해 둡니다.

의 CPU 사용률에 대한 CloudWatch 지표입니다CPUUtilization.

진단 - 근본 원인 찾기

다음은 CPU 스파이크의 인스턴스와 타임라인을 식별한 후 CPU 사용량에 큰 영향을 미치는 원인을 진단하는 것입니다. CPU 급증을 일으킬 수 있는 여러 가지 이유가 있으므로에서 로 시작하는 원인이 무엇인지 식별해 보겠습니다.

연결: DatabaseConnections 및를 포함한 CloudWatch 지표를 확인합니다. 연결이 급증하고 CPU 급증 시간과 일치하는 DatabaseConnectionsMax경우 짧은 시간 동안의 연결 급증이 CPU 급증의 원인일 수 있습니다.

쿼리: 연결이 아닌 경우 쿼리가 원인일 수 있습니다. 성능 인사이트를 활성화한 경우 인스턴스의 성능 인사이트 콘솔로 이동하여 인스턴스의 쿼리를 확인합니다. 쿼리를 살펴볼 또 다른 것은 프로파일러에서 가져온 것입니다.

해결 - 문제 해결

연결 버스트: 연결 버스트가 CPU 급증의 원인인 경우 애플리케이션에서 연결을 재사용하거나 연결 풀링을 구현하는 것이 좋습니다. 높은 연결 최적화에 대한 자세한 내용은 섹션을 참조하세요Amazon DocumentDB 연결 문제.

쿼리 배포: 기본 인스턴스의 읽기 쿼리로 인해 CPU 스파이크가 발생하는 경우 쿼리 결과가 최종적으로 일치할 수 있는 경우 읽기 작업을 복제본 인스턴스로 리디렉션하는 것이 좋습니다.

쿼리 최적화: 쿼리 또는 쿼리 세트로 인해 CPU가 급증하는 경우 쿼리가 인덱스를 사용하지 않는 경우 인덱스를 추가하는 등 쿼리를 최적화하는 것이 좋습니다. 쿼리 최적화에 대한 자세한 내용은 섹션을 참조하세요쿼리 실행 속도가 느림.

인스턴스 크기 조정: 최적화 작업 후에도 CPU 사용률이 지속적으로 높은 경우 워크로드 요구 사항을 효과적으로 처리할 수 있도록 CPU 용량이 더 많은 더 큰 인스턴스 클래스로 업그레이드합니다.

서버리스: 단기 CPU 급증을 일으키는 예측할 수 없는 워크로드의 경우 사용을 고려하세요Amazon DocumentDB Serverless 사용. 서버리스 인스턴스는 필요에 따라 자동으로 리소스를 확장하므로 이러한 워크로드에 고정 인스턴스 크기를 프로비저닝할 필요가 없습니다.