oracle-plan babysitter 스케줄러 v3 → v4.2

TL;DR

v3: PENDING own 잡을 scontrol update qos=extra로 자동 승격 + 코스트 캡 15/24 → 25/40
v4: "무조건 extra 승격"이 own 회전을 놓치는 것을 실측 → 제출 시각순 상위 K=2개는 own에 파킹
v4.1: own 파킹 순서를 FIFO에서 잔여 작업량(LPT) 기반으로 — 6h짜리 샤드가 27h짜리보다 먼저 own을 차지해 꼬리 지연 6~8h가 나던 것을 수정
v4.2: squeue 일시 장애(Connection reset)를 "잡 없음"으로 오독해 RUNNING 잡을 중복 재제출하던 사고 이후 프로브 실패 시 재제출 판단 보류

버전 (v3→v4.2)

25/40

코스트 캡(구15/24)

~15.5h

전개 시간(03:28→18:54)

1 배경 / 목적

실험 3(Oracle-plan) 본 런은 own GPU 8장을 다른 세션과 나눠 쓰는 구조라, own만 기다리면 하루 종일 4~5샤드에 묶인다(260922 17:08 실측: 오라클 4 + goalv2 4 = own 8/8 포화). 사용자 결정(260923 "extra도 잘 활용해보자")으로 배치 재제출 스크립트(babysit.sh)의 own/extra 혼합 스케줄링 정책 개선에 착수했다.

기존 한계: own 전용 대기는 안전하지만(preempt 없음) 처리량이 낮고, 정적 규칙 하나로는 실측에서 바로 다음 문제가 드러났다 — v3→v4.2는 전부 그날 실제로 터진 장애에 대한 대응이었다.

2 작업 내용

버전	시각	변경	촉발 원인
v3	03:28	PENDING own 잡 → 다음 주기에 `scontrol update qos=extra` 자동 승격. 완료 셀은 DONE_GLOB으로 스킵 + babysitter 재제출이라 preempt 손실은 진행 중 편 1개분뿐. 코스트 캡 15/24→25/40(총액 궤도 $190 불변, 상한 $420)	own 8/8 포화로 하루 종일 4~5샤드 고정(260922 17:08)
v4	12:03	제출 시각순 상위 `PARK_OWN=2`개는 own 큐에 계속 파킹, 나머지만 extra로 승격	빈 own 슬롯은 Slurm이 이미 대기 중인 own 잡에 즉시 배정 — v3의 "무조건 승격"은 own 회전을 전부 놓침(다른 세션 own 대기 잡이 받고 오라클 extra 7개는 0, 11:46 실측)
v4.1	15:26	own 파킹 순서를 FIFO → 잔여 행수 × 가족별 행당 실측 시간(LPT) 정렬로 전환	15:23 실측: restore_s1 잔여 64행≈27h·s4 47행≈20h가 extra 대기인데, 6h짜리 s2가 FIFO 1순위로 own 파킹 → 전체 완료 시각 기준 꼬리 6~8h 손해
v4.2	18:54	주기 머리에서 squeue 프로브 실패 시 그 주기 스킵, 샤드별 조회 실패도 재제출 판단 보류	18:52 컨트롤러 일시 오류(Connection reset by peer)로 squeue 빈 출력이 "잡 없음"으로 읽혀 RUNNING 중이던 find_s2·restore_s0을 중복 재제출(152054·152055, 시작 전 취소)

v3 근거: find_s0 행당 $0.080 vs s1 $0.052, restore_s0 $0.27 — 편차 큰 샤드가 옛 캡(15/24)에 먼저 걸려 find_s0은 완주 직전, restore_s0/s5/s6는 완주 전에 멈췄을 것. 캡은 안전 브레이크이지 예산이 아니다. OVER_COST_CAP 뒤 캡을 올렸으면(jsonl 누적 < 현재 캡) 재제출, 아니면 사람 몫 — 무한 재제출은 금지. v4 근거: RUNNING extra→own 승격은 불가(실측 확인). 두 가족 babysitter가 오라클 전체에 같은 결정론적 규칙을 적용하므로 파킹 결과가 멱등.

3 결과

v3 배포 첫 주기: 6잡 승격, find_s3 즉시 GPU 확보
scontrol update가 "Access/permission denied"를 찍고도 실제로는 반영됨을 squeue QOS 열로 확인 (260922 find_s2가 extra에서 PREEMPTED → 정상 자동 복구 실측)
v4 이후 own 회전 정상화 — own 파킹 K=2로 처리량과 안전성 균형
v4.2 배포 후 동일 유형 중복 재제출 재발 없음

핵심 발견: 클러스터 포화(core 70/72, 여유 2)에서도 own 4(오라클: find_s0· restore_s3/s4/s7)를 유지하며 속도 8행/h로 남은 ~470행을 소화 중(ETA ~2일) — own/extra 혼합 정책이 처리량 병목을 완화했다.

4 Takeaway

의미

own/extra 혼합 스케줄링은 정적 규칙 하나(무조건 승격)로 안 풀린다 — own 슬롯 재배정 규칙(Slurm이 대기 own 잡에 즉시 준다), 샤드별 잔여 작업량 비대칭(LPT 필요성), 컨트롤러 일시 장애까지 세 가지 서로 다른 실패 모드가 하루 안에 실측으로 드러났고, v3→v4.2 네 번의 반복은 전부 "실측 → 원인 특정 → 규칙 보정"의 대응이었다. babysitter는 이제 own↔extra 승격/파킹/장애 감지를 겸하는 작은 스케줄러가 됐다.

5 Next Steps

미해결 한계

오라클 own 할당은 여전히 4/8 — 다른 세션 잡(goalv2·rsprobe)과 협의 없이는 own 8로 못 올린다. 사용자 결정 대기.

다음 작업

남은 ~470행(find 173·restore 299) 완주까지 모니터링 지속. 완주 후 archive_oracle_plan.py --out-dir final_results/oracle_plan_v1_260923(_PARTIAL 제거)로 최종 보관소 재생성.