Amazon Redshift 리더 노드에서 CPU 사용량이 높은 이유는 무엇입니까?

최종 업데이트 날짜: 2020년 12월 15일

Amazon Redshift 클러스터의 리더 노드에서 CPU 사용률이 높습니다. 이유가 무엇입니까?

간략한 설명

Amazon Redshift 클러스터의 리더 노드는 데이터베이스 작업을 수행하기 위한 실행 계획을 구문 분석하고 개발합니다. 리더 노드는 또한 쿼리를 최종 처리하고 데이터를 클라이언트에 반환하기 전에 데이터의 병합 또는 정렬을 수행합니다. 데이터베이스 작업의 복잡성 또는 리소스 집약도에 따라 클러스터의 리더 노드에 대한 CPU 사용률이 급증할 수 있습니다.

특히 다음과 같은 이유로 리더 노드의 CPU 사용률이 급증할 수 있습니다.

  • 데이터베이스 연결 증가
  • 쿼리 컴파일 및 재컴파일
  • 동시 연결 수가 많음
  • WLM에서 실행되는 동시 쿼리 수가 너무 많음
  • 리더 노드 전용 함수 및 카탈로그 쿼리

참고: 리더 노드를 차지하는 특정 프로세스는 확인할 수 없습니다. STV_RECENTS 테이블을 사용하여 특정 시간에 실행 중인 조회를 확인할 수 있습니다.

해결 방법

데이터베이스 연결 증가

클라이언트 서버는 리더 노드를 통해 Amazon Redshift 클러스터와 통신합니다. 데이터베이스 연결 수가 늘어나는 경우 이러한 연결을 처리하기 위해 CPU 사용률이 증가합니다. Amazon CloudWatch 지표를 확인하여 DatabaseConnections 제한이 초과되지 않았는지 확인합니다.

쿼리 컴파일 및 재컴파일

Amazon Redshift는 각 쿼리 실행 계획에 대한 코드를 생성하고 컴파일합니다. 쿼리 컴파일 및 재컴파일은 리소스 집약적인 작업이므로 리더 노드의 CPU 사용량이 많아질 수 있습니다. 그러나 쿼리 컴파일 또는 재컴파일 작업이 완료되면 CPU 성능이 정상으로 돌아와야 합니다.

또한 Amazon Redshift는 컴파일된 코드를 캐시합니다. 쿼리가 제출될 때 Amazon Redshift는 사용 가능한 세그먼트를 재사용하며 나머지 세그먼트는 다시 컴파일됩니다. 따라서 이 프로세스로 인해 리더 노드의 CPU 사용량이 높을 수 있습니다.

참고: Amazon Redshift 클러스터가 재부팅된 후에도 이전 쿼리의 캐시가 계속 유지될 수 있습니다. 쿼리가 이전에 캐시된 경우 Amazon Redshift는 쿼리를 실행하지 않습니다. 패치가 적용되면 모든 캐시가 제거됩니다.

각 쿼리 세그먼트의 컴파일 시간(초) 및 세그먼트 실행 위치를 확인하려면 SVL_COMPILE 시스템 보기를 사용하세요.

select userid,xid,pid,query,segment,locus,starttime, endtime,
datediff(second,starttime,endtime) as TimetoCompile,compile from svl_compile;

동시 연결 수가 많음

연결이 많을수록 동시성이 높아지고 Amazon Redshift 클러스터의 트랜잭션이 증가할 수 있습니다. 트랜잭션이 증가하면 리더 노드의 CPU 사용률이 높아질 수 있습니다.

동시 연결을 확인하려면 다음 쿼리를 실행합니다.

select s.process as process_id,
c.remotehost || ':' || c.remoteport as remote_address,
s.user_name as username,
s.starttime as session_start_time,
s.db_name,
i.starttime as current_query_time,
i.text as query 
from stv_sessions s
left join pg_user u on u.usename = s.user_name
left join stl_connection_log c
on c.pid = s.process
and c.event = 'authenticated'
left join stv_inflight i 
          on u.usesysid = i.userid
          and s.process = i.pid
where username <> 'rdsdb'
order by session_start_time desc;

그런 다음 PG_TERMATE_BACEND를 사용하여 활성 세션을 닫습니다.

WLM에서 실행되는 동시 쿼리 수가 너무 많음

모든 클라이언트 연결은 리더 노드를 통해 처리됩니다. Amazon Redshift의 리더 노드는 클라이언트 서버로 데이터를 반환하기 전에 쿼리를 구문 분석, 최적화 및 컴파일합니다. 또한 리더 노드는 작업을 컴퓨팅 노드에 배포하여 최종 정렬 또는 집계를 수행합니다. 쿼리 동시성이 높으면 리더 노드 수준에서 CPU 사용량이 증가할 수 있습니다. 또한 일부 데이터베이스 작업은 리더 노드 수준에서만 적용될 수 있습니다. 예를 들어 LIMIT 절이 있는 쿼리의 경우 데이터가 재배포되기 전에 리더 노드에 제한이 적용되기 때문에 CPU 사용량이 높을 수 있습니다.

동시 쿼리 수와 CPU 사용량 간에 상관관계가 있는지 확인하려면 Amazon CloudWatch에서 WLMRunningQueriesCPUutilization 지표를 확인하세요.

그런 다음 CPU를 많이 소비하는 쿼리를 확인합니다.

SELECT userid, query, xid, aborted,
ROUND(query_cpu_time::decimal,3),
query_execution_time,
segment_execution_time,
substring(querytxt,1,250)
FROM stl_query
JOIN
(SELECT query,
query_cpu_time,
query_execution_time,
segment_execution_time
FROM svl_query_metrics_summary
ORDER BY 2 DESC) a USING (query)
WHERE userid>1
AND starttime BETWEEN '2019-12-02 22:00:00' and '2019-12-05 23:59:59'
ORDER BY 5 DESC;

출력을 검토하여 리더 노드에서 처리되는 쿼리와 CPU 사용량을 늘리는 기타 이상치 쿼리를 확인합니다.

참고: 해당 쿼리에 대해 쿼리 성능을 튜닝하는 것이 가장 좋습니다. 리더 노드 용량을 늘리고 컴퓨팅 노드를 추가하는 대신 큰 노드 유형을 선택하는 것이 좋습니다.

리더 노드 전용 함수 및 카탈로그 쿼리

Amazon Redshift는 리더 노드에서 지원되는 특정 SQL 함수를 구현하도록 설계되었습니다. 리더 노드 함수카탈로그 쿼리를 오버로드하는 복잡한 쿼리가 있는 경우 리더 노드에서 CPU 사용률이 급증할 수 있습니다. 자세한 내용은 리더 노드에서 지원되는 SQL 함수를 참조하세요.

카탈로그 테이블을 참조하는 단계(리더 노드에서만 실행)를 식별하려면 EXPLAIN 계획을 확인합니다.

explain select * from pg_class;
                           QUERY PLAN                          
----------------------------------------------------------------
 LD Seq Scan on pg_class  (cost=0.00..24.57 rows=557 width=243)

출력에서 LD 접두사를 확인합니다. 이 예에서 LD 접두사는 "LD Seq Scan on pg_class(cost=0.00..24.57 rows=557 width=243)"에 표시됩니다. LD 접두사는 쿼리가 리더 노드에서 단독으로 실행되고 있음을 나타내며, 이로 인해 CPU 사용량이 급증할 수 있습니다.</p


이 문서가 도움이 되었나요?


결제 또는 기술 지원이 필요합니까?