CPU

이 이벤트는 스레드가 CPU에서 활성 상태이거나 CPU를 대기 중일 때 발생합니다.

지원되는 엔진 버전

이 대기 이벤트 정보는 모든 버전의 RDS for PostgreSQL과 관련이 있습니다.

컨텍스트

중앙 처리 장치는 명령을 실행하는 컴퓨터의 구성 요소입니다. 예를 들어 CPU 명령은 연산 연산을 수행하고 메모리에서 데이터를 교환합니다. 쿼리가 데이터베이스 엔진을 통해 수행하는 명령 수를 늘리면 쿼리 실행 시간이 늘어납니다. CPU 스케줄링은 프로세스에 CPU 시간을 부여합니다. 스케줄링은 운영 체제 커널에 의해 조정됩니다.

주제

• 이 대기 시간이 언제 발생하는지 확인하는 방법
• DBloadCPU 지표
• os.cpuUtilization 지표
• CPU 스케줄링의 원인

이 대기 시간이 언제 발생하는지 확인하는 방법

CPU 대기 이벤트는 백엔드 프로세스가 CPU에서 활성 상태이거나 CPU를 기다리고 있음을 나타냅니다. 쿼리에 다음 정보가 표시될 때 발생한다는 것을 알고 있습니다.

• pg_stat_activity.state 열이 active 값을 갖고 있습니다.

• pg_stat_activity의 wait_event_type과 wait_event 열은 모두 null입니다.

CPU를 사용하거나 대기 중인 백엔드 프로세스를 보려면 다음 쿼리를 실행하세요.

SELECT * 
FROM   pg_stat_activity
WHERE  state = 'active'
AND    wait_event_type IS NULL
AND    wait_event IS NULL;

DBloadCPU 지표

CPU 성능 개선 도우미의 지표는 DBLoadCPU입니다. DBLoadCPU의 값은 Amazon CloudWatch 지표 CPUUtilization의 값과 다를 수 있습니다. 후자의 지표는 데이터베이스 인스턴스에 대한 HyperVisor에서 수집됩니다.

os.cpuUtilization 지표

성능 개선 도우미 운영 시스템 지표는 CPU 사용률에 대한 자세한 정보를 제공합니다. 예를 들어 다음 지표가 표시될 수 있습니다.

• os.cpuUtilization.nice.avg

• os.cpuUtilization.total.avg

• os.cpuUtilization.wait.avg

• os.cpuUtilization.idle.avg

성능 개선 도우미는 데이터베이스 엔진의 CPU 사용량을 os.cpuUtilization.nice.avg와 같이 보고합니다.

CPU 스케줄링의 원인

운영 체제(OS) 커널은 CPU의 스케줄링을 처리합니다. CPU가 활성 상태이면 프로세스는 스케줄링될 때까지 기다려야 할 수 있습니다. CPU는 계산을 수행하는 동안 활성 상태입니다. 실행 중이 아닌 유휴 스레드, 즉 메모리 I/O에서 대기하는 유휴 스레드가 있는 경우에도 CPU는 활성 상태입니다. 일반적인 데이터베이스 워크로드에서는 이 유형의 I/O가 지배적입니다.

다음 조건이 충족되면 프로세스가 CPU에 스케줄링될 때까지 대기할 수 있습니다.

• CloudWatch CPUUtilization 지표가 100%에 가깝습니다.

• 평균 로드가 vCPU 수보다 크므로 부하가 많음을 나타냅니다. 성능 개선 도우미의 OS 지표 섹션에서 loadAverageMinute 지표를 찾을 수 있습니다.

대기 증가의 가능한 원인

이 이벤트가 정상 상태보다 많이 발생하여 성능 문제를 나타낼 수 있는 경우 일반적인 원인은 다음과 같습니다.

주제

• 갑작스러운 스파이크의 원인
• 장기 고주파의 원인
• 코너 케이스

갑작스러운 스파이크의 원인

갑작스런 스파이크의 가장 큰 원인은 다음과 같습니다.

• 애플리케이션이 데이터베이스에 대한 동시 연결을 너무 많이 열었습니다. 이 시나리오를 '연결 폭풍'이라고 합니다.

• 다음 방법 중 하나로 애플리케이션 워크로드가 변경되었습니다.

  • 새 쿼리

  • 데이터 집합 크기 증가

  • 인덱스 유지 관리 또는 생성

  • 새로운 함수

  • 새로운 연산자

  • 병렬 쿼리 실행의 증가

• 쿼리 실행 계획이 변경되었습니다. 경우에 따라 변경으로 인해 버퍼가 증가할 수 있습니다. 예를 들어, 쿼리는 이전에 인덱스를 사용했을 때의 순차적 스캔을 사용하고 있습니다. 이 경우 쿼리는 동일한 목표를 달성하기 위해 더 많은 CPU가 필요합니다.

장기 고주파의 원인

장기간에 걸쳐 재발하는 이벤트의 가장 큰 원인은 다음과 같습니다.

• 너무 많은 백엔드 프로세스가 CPU에서 동시에 실행되고 있습니다. 이러한 프로세스는 병렬 작업자가 될 수 있습니다.

• 쿼리는 많은 수의 버퍼가 필요하기 때문에 차선적으로 수행됩니다.

코너 케이스

실제 원인으로 판명될 가능성이 있는 원인이 없다면 다음과 같은 상황이 발생할 수 있습니다.

• CPU가 프로세스를 안팎으로 교환하고 있습니다.

• 방대한 페이지 기능이 꺼진 경우 CPU가 페이지 테이블 항목을 관리하고 있을 수 있습니다. 이 메모리 관리 기능은 마이크로, 스몰, 미디엄 DB 인스턴스 클래스를 제외한 모든 DB 인스턴스 클래스에 대해 기본적으로 사용 설정되어 있습니다. 자세한 내용은 RDS for PostgreSQL용 방대한 페이지 섹션을 참조하세요.

작업

CPU 대기 이벤트가 데이터베이스 활동을 지배하는 경우 반드시 성능 문제를 나타내지는 않습니다. 성능이 저하되는 경우에만 이 이벤트에 응답하세요.

주제

• 데이터베이스로 인해 CPU 증가가 발생하는지 조사합니다.
• 연결 수 증가 여부 확인
• 워크로드 변경에 대응

데이터베이스로 인해 CPU 증가가 발생하는지 조사합니다.

성능 개선 도우미의 os.cpuUtilization.nice.avg 지표를 검토합니다. 이 값이 CPU 사용량보다 훨씬 작다면 데이터베이스가 아닌 프로세스가 CPU의 주요 기여자입니다.

연결 수 증가 여부 확인

Amazon CloudWatch의 DatabaseConnections 지표를 검토합니다. 작업은 CPU 대기 이벤트 증가 시기 동안 증가 또는 감소 여부에 따라 달라집니다.

연결이 증가했습니다.

연결 수가 증가했다면, CPU를 사용하는 백엔드 프로세스 수를 vCPU 수와 비교하세요. 가능한 시나리오는 다음과 같습니다.

• CPU를 사용하는 백엔드 프로세스 수가 vCPU 수보다 적습니다.

  이 경우 연결 수는 문제가 되지 않습니다. 그러나 계속해서 CPU 사용률을 줄이려고 할 수도 있습니다.

• CPU를 사용하는 백엔드 프로세스 수가 vCPU 수보다 적습니다.

  이 경우에는 다음 옵션을 고려하세요.

  • 데이터베이스에 연결된 백엔드 프로세스 수를 줄입니다. 예를 들어 RDS 프록시와 같은 연결 풀링 솔루션을 구현합니다. 자세한 내용은 Amazon RDS 프록시 사용 섹션을 참조하세요.

  • 인스턴스 크기를 업그레이드하여 vCPU 수를 늘립니다.

  • 해당하는 경우 일부 읽기 전용 워크로드를 리더 노드로 리디렉션하세요.

연결이 증가하지 않았습니다.

성능 개선 도우미의 blks_hit 지표를 검토합니다. blks_hit의 증가와 CPU 사용량 사이의 상관관계를 찾습니다. 가능한 시나리오는 다음과 같습니다.

• CPU 사용량 및 blks_hit이 상관관계가 있습니다.

  이 경우 CPU 사용량에 연결된 최상위 SQL 문을 찾아 계획 변경을 찾습니다. 다음과 같은 기술을 사용할 수 있습니다.

  • 계획을 수동으로 설명하고 예상 실행 계획과 비교합니다.

  • 초당 블록 히트와 초당 로컬 블록 히트가 증가하는지 확인합니다. 성능 개선 도우미의 대시보드의 상위 SQL 섹션에서 환경설정을 선택합니다.

• CPU 사용량 및 blks_hit이 상관관계가 없습니다.

  이 경우 다음 중 한 가지라도 발생하는지 확인합니다.

  • 애플리케이션이 데이터베이스에 급속하게 연결되고 데이터베이스와의 연결이 끊어지고 있습니다.

    log_connections와 log_disconnections를 켜 이 동작을 진단하고, 그런 다음 PostgreSQL 로그를 분석합니다. pgbadger 로그 분석기 사용을 고려하세요. 자세한 내용은 https://github.com/darold/pgbadger 섹션을 참조하세요.

  • OS에 과부하가 걸렸습니다.

    이 경우 성능 개선 도우미는 백엔드 프로세스가 평소보다 오랜 시간 동안 CPU를 사용하고 있음을 보여줍니다. 성능 개선 도우미 os.cpuUtilization 지표 또는 CloudWatch CPUUtilization 지표에서 증거를 찾습니다. 운영 체제에 과부하가 걸린 경우 향상된 모니터링 지표를 살펴보고 더 자세히 진단하세요. 특히 프로세스 목록과 각 프로세스에서 소비되는 CPU 비율을 살펴보세요.

  • 상위 SQL 문이 너무 많은 CPU를 소비하고 있습니다.

    CPU 사용량에 연결된 문을 검사하여 CPU를 더 적게 사용할 수 있는지 확인합니다. EXPLAIN 명령을 실행하고 가장 큰 영향을 미치는 계획 노드에 중점을 둡니다. PostgreSQL 실행 계획 비주얼라이저를 사용하는 것이 좋습니다. http://explain.dalibo.com/ 섹션을 참조해 이 도구를 사용해 보세요.

워크로드 변경에 대응

워크로드가 변경된 경우 다음 변경 유형을 찾습니다.

새 쿼리

새 쿼리가 예상되는지 확인합니다. 그렇다면 실행 계획과 초당 실행 횟수가 예상되는지 확인합니다.

데이터 집합 크기 증가

파티셔닝이 아직 구현되지 않은 경우 파티셔닝이 도움이 될지 확인합니다. 이 전략은 쿼리가 검색해야 하는 페이지 수를 줄일 수 있습니다.

인덱스 유지 관리 또는 생성

유지 관리 일정이 예상되는지 확인합니다. 모범 사례는 피크 활동 이외의 유지 관리 활동을 예약하는 것입니다.

새로운 함수

테스트 중에 이러한 함수가 예상대로 작동하는지 확인합니다. 특히 초당 실행 횟수가 예상되는지 확인합니다.

새로운 연산자

테스트 중에 이러한 함수가 예상대로 작동하는지 확인합니다.

병렬 쿼리 실행 증가

다음 상황 중 한 가지라도 발생했는지 확인합니다.

• 포함된 관계식 또는 인덱스의 크기가 갑자기 커져 min_parallel_table_scan_size 또는 min_parallel_index_scan_size와 크게 다릅니다.

• parallel_setup_cost 또는 parallel_tuple_cost에 최근 변경 사항이 적용되었습니다.

• max_parallel_workers 또는 max_parallel_workers_per_gather에 최근 변경 사항이 적용되었습니다.