squeue -o "%Q %V"로 원인 특정: 살아있는 잡은 최초 제출분뿐이고 PENDING은 전부 babysitter의 재제출 — own QOS 우선순위는 나이(age) 기반인데 --max-episodes 3이 3편마다 재제출을 강제해 나이가 매번 0으로 리셋된다.--max-episodes 3→5(sjob --json 실측 3편에서 이미 99.5/128GB=78%) + --mem 128→200GB + core-own → core-extra 전환 → 처리량 2~5행/시 → 18행/시, preempt 0건(1시간).share는 이 워크로드에 못 쓴다 — 3회 전부 PREEMPTED, 행 0개(첫 체크포인트까지 필요한 기동 10분 > PreemptExemptTime 5분).파일럿 10칸(GC 0.125)을 마치고 사용자 승인($127)을 받아 본 런(682칸 = main 534 + tagmem 148)을 제출했다. 조건은 파일럿과 동일하되 SBENCH_PICK_FACE_EXACT=0(사용자 결정 — 정면 보정 없이 find/restore와 통일). 그런데 행이 쌓이는 속도가 계속 떨어졌다 — 품질 지표가 아니라 처리량이 문제였고, 원인은 코드가 아니라 스케줄러 쪽이었다.
tmp/routine_online/submit_main.sh 신규 — 세트(main/tagmem)별 전략 묶음이 달라 셀 파일을 분리. $0 프리플라이트를 실행 스냅샷 src_r1로 돌려 534+148=682칸 전부 통과 확인. 그 과정에서 프리플라이트 결함 2건 발견 — resume 작업 때 넣은 코드가 옛 스냅샷에서 안 도는 문제(slice_ingest_for_cut 무조건 import·p.cut_f1 무조건 접근) → resume 전용 코드는 resume 경로 안에서만 부르도록 수정.
| 잡 | 제출 | 상태 |
|---|---|---|
| rtmain_main_s1 | 09-21 19:08 | RUNNING |
| rtmain_main_s3 | 09-21 19:08 | RUNNING |
| rtmain_main_s0 | 09-22 02:24 | PENDING |
| rtmain_tagmem_s0/s1 | 09-22 02:35~02:41 | PENDING |
--max-episodes 3 → 3편 돌고 종료 → 재제출 → 나이 0 → own 줄 맨 뒤 → 대기. 게다가 own 8장을 같은 사용자의 다른 캠페인(oracle 8잡·rescue 5잡·v12 4잡)과 공유해 줄 뒤로 갈 때마다 그만큼 밀렸다.| 시점 | routine RUNNING | tagmem | 처리량 |
|---|---|---|---|
| 04:02 | 1 / 6 | 11/148 (6.3h 정지) | 2~5행/시 |
| 04:49 | 6 / 6 | 12/148 (재개) | — |
| 06:19 | 6 / 6 | 16/148 | 18행/시 |
전환 후 preempt 0건(1시간), 남은 시간 추정 ~32시간, 비용 환산 $153.
share로 옮겼다가 3회 전부 PREEMPTED(10:30/11:31/13:37), 행 0개. 온라인 런은 첫 행까지 모델 서버 로드 ~10분 + 씬 빌드가 필요한데(tagmem 첫 행 secs 2401), share는 PreemptExemptTime=5min 직후 축출돼 첫 체크포인트에 도달하지 못한다. DONE_GLOB 재개도 못 구한다 — 쓴 행이 없으니 이어받을 것이 없다. own 대기보다 나쁘다.share 실패를 보고 승인받은 extra 전환까지 같이 own으로 되돌렸다. 그러나 같은 시간대에 core-extra로 돈 main_s2는 47분 생존하며 행 2개를 썼고, 다른 세션도 v12 4잡을 extra에서 돌리고 있었다. share는 남의 own과 extra 둘 다에게 쫓기고, extra는 own에게만 쫓긴다. → 원래 결정대로 복원, RUNNING 1→6·preempt 0건.
tagmem이 유독 자주 죽은 것은 tagmem이라서가 아니라 재제출 직후라 항상 가장 어렸기 때문 — 기동 15분이 필요한 워크로드에서 이 규칙은 치명적이다. --max-episodes를 올려 기동 노출 횟수 자체를 줄이는 것이 해법.
세트별 정체를 총 행수로만 봐서 main이 밀어올리는 동안 tagmem 6시간 정지를 놓쳤다 → 세트별 감지로 변경. 정체 경보가 1회성이라 해소 안 되는 동안 조용했다 → 2시간마다 재알림 + routine RUNNING이 2개 이하로 떨어지면 캠페인별 배분과 함께 경보 추가.
품질 문제가 아니라 스케줄링 문제였고, 증상(잡이 안 돈다)에서 원인(재제출이 나이를 잃는다)까지 가는 데 squeue -o "%Q %V" 한 번이면 됐다 — 처음부터 우선순위를 봤어야 했다. 여유 자원이 있다는 사실만으로 옮기면 안 된다 — 축출 주기와 기동 비용이라는 두 시간 척도를 비교해야 하고, 그걸 안 해서 40분간 GPU 4장을 태우고 산출물 0을 얻었다. 감시는 집계값이 아니라 진행이 멈출 수 있는 단위마다 걸어야 한다. 벽시계 추정을 세 번 바꿨다(35h→55h→21h→32h) — 정상 속도가 1시간 이상 쌓이기 전에는 추정치를 말하지 않기로 했다.
본 런 완주 대기(130/682, 19%, 추정 ~32시간). 겉보기 성능 하락(GC 0.275→0.094)은 구간마다 편·전략 구성이 다른 탓 — 답 1개로 고정해도 0.297→0.091이지만 같은 전략끼리는 일관된 추세가 없다. 편 14개 중 7개가 전 칸 0점 — 그 집에서 파지가 아예 안 되는 것으로 보임. 최종 판단은 682칸 완료 후 편 난이도 보정(LOO)으로.
resume 전수 검증이 아직 미제출 — share에 맞는 작업(편당 230초·멱등·편 단위 독립)이지만 풀이 0이다. 본 런 GPU 여유가 생기면 투입.