クイズ: JobManager・TaskManager・スロット

독립(standalone) 배포에서 잡이 슬롯을 기다리며 멈춰 있다. ResourceManager 가 할 수 있는 일은?

• 새 TaskManager 프로세스를 띄워 슬롯을 늘린다
• 이미 붙어 있는 TaskManager 의 슬롯을 나눠 줄 뿐이다
• 다른 잡의 슬롯을 빼앗아 이 잡에 준다
• 잡의 병렬도를 슬롯 수에 맞게 낮춘다

TaskManager 한 대에 슬롯이 4개다. 슬롯이 실제로 나누는 자원은?

• CPU 코어 — 슬롯마다 코어 하나씩 고정된다
• JVM 힙 전체 — 슬롯마다 4분의 1씩 따로 잡힌다
• 관리 메모리 — 지금의 슬롯은 이것만 가른다
• 네트워크 대역 — 슬롯마다 같은 몫을 받는다

taskmanager.memory.process.size 를 4096m 로 줬는데 태스크 힙은 1GB 남짓이다. 가장 정확한 설명은?

• 설정 파일이 반영되지 않아 TaskManager 가 기본 크기(1728m)로 떴다
• JVM 이 최대 힙을 프로세스 크기의 4분의 1 로 묶어 두기 때문이다
• 관리 메모리가 힙 안에서 먼저 떼어 가고 남은 힙만 태스크에 주기 때문이다
• 프로세스 크기에서 메타스페이스·오버헤드·관리·네트워크·프레임워크 몫을 떼고 남은 것이 태스크 힙이다

작은 CSV 를 읽는 배치 잡에 parallelism.default = 4 를 줬는데 정점 병렬도가 전부 1 이다. 원인은?

• 적응형 배치 스케줄러가 자료 크기를 보고 병렬도를 다시 정했다
• 슬롯이 모자라 스케줄러가 병렬도를 깎았다
• SET 문은 배치 모드에서 무시된다
• CSV 형식은 병렬로 읽을 수 없다

체크포인트를 켜지 않은 잡이 예외로 죽었다. 예외 기록 맨 위 문장이 'Recovery is suppressed by NoRestartBackoffTimeStrategy' 다. 장애 보고서의 원인 칸에 적을 것은?

• NoRestartBackoffTimeStrategy — 재시작 전략이 잡을 죽였다
• JobException — 맨 위 예외가 곧 원인이다
• 스택의 마지막 Caused by 에 적힌 예외
• TaskManager 가 끊겼다는 사실

config.yaml 의 taskmanager.numberOfTaskSlots 를 2 에서 4 로 고쳤다. /overview 의 slots-total 이 4 가 되는 때는?

• 파일을 저장하는 즉시
• TaskManager 를 다시 띄운 뒤
• 다음 잡을 제출하는 순간
• JobManager 의 REST 를 새로 고칠 때