단일 노드 빌드의 CPU와 메모리 지표

Metrics telemetry는 단일 노드 변환의 자원 사용량을 시간에 따라 보여 줍니다. Job이 지표를 내보낸 경우에만 Metrics 탭이 표시됩니다.

화면 열기

Dataset Preview나 Data Lineage의 History에서 빌드를 선택하고 View build report를 엽니다. Builds의 전체 빌드 목록에서도 선택할 수 있습니다.

Gantt 차트 아래의 job 목록에서 하나를 고른 뒤 Telemetry > Metrics를 선택합니다.

빌드 job의 Metrics 탭

Memory utilization의 빨간 점선은 빌드가 요청한 메모리 한도입니다. 컨테이너가 한도를 넘으면 OOM으로 실패할 수 있습니다.

메모리 부족 사례

사용량이 계속 올라 한도에 도달하는 작업은 데이터의 메모리 사용과 memory_gb 또는 memory_mb를 확인합니다. 예를 들어 해당 작업에 필요한 양에 맞춰 32 GB로 늘릴 수 있습니다.

반대로 아래처럼 요청량에 훨씬 못 미치면 자원을 줄일 여지가 있습니다. 이 사례에서는 32 GB로 낮추는 구성을 검토할 수 있습니다.

메모리를 적게 사용하는 사례

32 GB는 모든 작업의 권장 기본값이 아닙니다. 실제 데이터 크기, 처리 단계와 peak 사용량을 기준으로 정합니다.

CPU utilization의 주황색 점선은 요청한 CPU 수입니다. 기본 요청은 2코어이며 스케줄러는 요청한 코어를 확보할 수 있는 호스트를 기다립니다.

호스트에 사용하지 않는 코어가 더 있으면 빌드가 이를 사용할 수 있습니다. 아래 사례에서는 2코어를 요청했지만 22코어를 사용했습니다.

요청한 CPU와 추가 사용량

추가 코어는 항상 제공되는 것이 아닙니다. 특정 실행에서 사용한 여유 코어를 다음 빌드의 보장 자원으로 간주하지 않습니다.

요청	선택 기준
1 CPU core	배정 가능한 호스트를 찾기 쉬워 시작 대기가 줄어들 수 있습니다. 실제 여유 CPU에 따라 실행 시간 변동이 커질 수 있습니다.
8 CPU cores	충분한 여유 호스트를 기다려 평균 시작 시간이 길어질 수 있습니다. 실행 중 확보하는 8코어를 기준으로 더 일정한 계산 시간을 계획할 수 있습니다.

CPU 요청과 메모리 한도는 서로 다른 역할입니다. 실행이 느린 이유가 CPU 계산인지, I/O 대기인지, 메모리 부족과 spill인지 구분하여 엔진과 자원을 조정합니다. Spark 분산 변환은 Spark Details의 지표 경로를 사용합니다.