오늘은 Redshift의 Cluster CPU가 갑자기 높아졌었던 당시 트러블 슈팅했던 내용에 대해서 다뤄보겠습니다.
CPU utilization의 경우 지난 6시간 기준으로 조회해 보았을때, 리더 노드가 아닌 컴퓨팅 노드들의 CPU가 평균 35%인 것을 확인하였습니다. 문제 시점 실행중인 쿼리는 없었음에도 Compute instance의 35% 전후 cpu 사용률을 보였습니다. 또한, 해당 시간 워크로드 실행 분석 차트에서도 plan / wait / comit / execution이 실행 중인 상태가 아니었습니다. 해당 내용의 경우, 부적절한 배포 키 또는 배포 스타일이 해당 문제의 원인이 아닐까 생각되었습니다. 왜냐하면, 부적절한 배포 키 혹은 배포 스타일은 노드 전체에서 분포 왜곡을 유발할 수 있기 때문입니다. Cluster Performance > Recommendation > Improve Query Performance with Sort Keys에서 해당 내용 확인하실 수 있는데, Aws에서 권장하는 내용으로 분석한 내용을 확인하실 수 있습니다. Sort Key와 함께 쿼리를 향상시킬 수 있으며,
Interleaved sort key 대신 복합 정렬키를 사용하시길 권장하고 있습니다.
복합 정렬 키가 있는 테이블은 VACUUM REINDEX 작업이 필요하지 않기 때문에 성능 향상 외에도 유지 관리 오버헤드를 크게 줄일 수 있습니다. 하지만, 테이블이 작을 경우에는 정렬 키가 없는 것이 더 효율적입니다. 이러한 경우 정렬 키를 사용하면 이점 없이 스토리지 오버헤드가 발생합니다. INTERLEAVED 정렬 키를 COMPOUND 정렬 키로 변경하거나 정렬 키를 제거하시려면 다음 쿼리를 실행하시기 바랍니다.
-- Database: "gip"ALTER TABLE /*iskru-20465d70-5745-4bb8-89e4-e09d6a3ce8eb-g0-0*/ "gipdw"."bd_sup_sub_sup_m" ALTER SORTKEY ("sub_sup_cd", "upper_sup_cd");ALTER TABLE /*iskru-20465d70-5745-4bb8-89e4-e09d6a3ce8eb-g0-1*/ "gipdw"."bd_sect_sect_m" ALTER SORTKEY NONE;
하기 쿼리는 장기 실행되는 쿼리가 무엇인지 확인하실 수 있는 쿼리입니다.
Select query, cpu_time / 1000000 as cpu_seconds
from stl_query_metrics where segment = -1 and cpu_time > 1000000000