Slurm 관련 질문

Ask a Question
1

안녕하세요 회사에서 일을 하고 있습니다. 근데 잘 안 되는게 있어서요. 다중 파티션으로 구성된 CPU-only 노드(우선순위 낮음)와 H100 GPU 노드(우선순위 높음)를 동시에 운용하면서, Fair-Share + QOS + 백필 스케줄러를 모두 활성화해 팀별 사용량 가중치 긴급 실험용 프리엠션과 그리고 1000 개 규모 잡 배열의 의존성을 한꺼번에 적용하려고 할 때,

  1. sacctmgr에서 각 연구실 계정에 가중치를 부여하고
  2. preempt_mode=REQUEUE와 PreemptType=QOS를 설정하며
  3. PriorityWeightFairshare/JobSize/Partition` 등 여러 우선순위 파라미터를 조정했음에도,

백필(backfill) 스케줄러가 예상보다 적게 개입하여 GPU 노드가 빈 채 남아 있거나, 반대로 CPU 파티션 잡이 과도하게 선점되는 현상이 반복됩니다.

이 상황에서

  • (a) bf_max_job_user, bf_window, bf_yield_interval 같은 백필 관련 파라미터를 어떻게 튜닝해야 하고,
  • (b) TRESBillingWeights와 QOS별 GrpsTRES 설정을 어떤 식으로 맞춰야 하며,
  • (c) 실시간으로 우선순위·페어셰어 변동을 모니터링할 수 있는 CLI/GUI 툴 혹은 sdiag 출력을 해석하는 방법,
  • (d) GPU 파티션의 미사용 슬롯을 최소화하면서도 CPU 잡 프리엠션이 너무 잦아지지 않도록 하는 균형 전략,

을 종합적으로 설계·검증하려면 구체적으로 어떤 절차와 설정(예: PriorityFlags=SMALL_RELATIVE_TIME, AllowQosPreemption=ON, over_time_limit)을 거치는 것이 좋을까요?”
슬러럼 20.11입니다

1 Like
8

[CloudBro AI Bot Response]
아주 수준 높은 슬러럼(Slurm) 운영 환경에서 고민하시는 부분이네요. 말씀하신 CPU-only(저우선), H100 GPU(고우선) 노드의 다중 파티션, Fair-Share+QOS+백필+잡 배열 의존성, 그리고 프리엠션까지 모두 활용하는 구성을 최적화하려면 여러 가지를 동시에 고려해야 합니다. 아래에 (a)~(d) 각각에 대한 실전적인 가이드와 함께, 전체적인 설계·검증 절차도 정리해드릴게요.

(a) 백필 파라미터 튜닝

  • bf_max_job_user: 한 유저가 백필로 동시에 실행 가능한 잡 수 제한입니다. 너무 낮으면 대기열이 잘 안 풀리고, 너무 높으면 특정 유저가 자원을 과도하게 점유할 수 있습니다. 잡 배열이 많으면 100~500 수준으로 넉넉하게 잡아보세요.
  • bf_window: 백필 스케줄러가 미래로 얼마나 길게 자원 예약을 예측할지(초 단위)입니다. 잡 대기 시간이 길고, 긴 잡이 많으면 1~2시간(3600~7200초)로 늘려보세요.
  • bf_yield_interval: 백필 스케줄러가 메인 스케줄러에 컨트롤을 넘기는 주기(초)입니다. 너무 짧으면 오버헤드, 너무 길면 응답성이 떨어집니다. 60~120초 정도가 일반적입니다.
  • 참고: 공식 문서(https://slurm.schedmd.com/backfill.html)와 StackOverflow, GitHub 이슈 등에서 비슷한 규모(잡 배열 1000개 이상)의 사례를 찾아 비교 조정이 좋습니다.

(b) TRESBillingWeights, QOS별 GrpTRES 설계

  • TRESBillingWeights: CPU, GPU, 메모리 등 자원별 가중치를 설정합니다. GPU 노드가 훨씬 비싸고 희소하다면, 예를 들어 TRESBillingWeights="CPU=1.0,Mem=0.1G,gres/gpu=10.0"처럼 GPU 가중치를 높게 설정해 팀별 공정성 및 우선순위에 반영하세요.
  • QOS별 GrpTRES: QOS마다 팀/사용자별로 동시에 쓸 수 있는 GPU, CPU, 메모리 양을 제한하는 옵션입니다. GPU QOS에는 GrpTRES=gres/gpu=4 등으로 제한, CPU QOS에는 넉넉하게 할당하되, GPU QOS에 더 빡빡하게 걸어두면 GPU 자원이 빈 채로 남는 일이 줄어듭니다.
  • 참고: CNCF, GitHub, Slurm mailing list 등에서 대규모 GPU 클러스터 운영 사례를 참고하면 실무적으로 도움이 됩니다.

(c) 실시간 우선순위/페어셰어 모니터링

  • CLI:
    • sprio -l: 잡별 우선순위 상세 내역 확인
    • sshare -l: 사용자/계정별 페어셰어 점수 및 사용량 확인
    • sdiag: 스케줄러 상태, 백필 통계, 페어셰어 적용 현황 등 상세 진단 정보
  • GUI:
  • sdiag 해석:
    • Main schedule statistics 및 Backfilling stats에서 백필 시도/성공률, Priority weights에서 가중치 반영 현황을 볼 수 있습니다.
    • Fairshare factor와 Job Size factor 등이 기대와 다르게 반영되는지 체크

(d) GPU 미사용 최소화 & CPU 잡 과도 프리엠션 방지

  • QOS 프리엠션 정책:
    • GPU QOS의 PreemptType=QOS, PreemptMode=REQUEUE로 설정
    • CPU QOS에는 프리엠션 우선순위를 낮추거나, 특정 QOS만 프리엠션 허용
  • PriorityFlags=SMALL_RELATIVE_TIME:
    • 작은 잡이 오래 대기하지 않도록 우선순위에 대기 시간 비율을 반영
  • AllowQosPreemption=ON:
    • QOS 기반 프리엠션 활성화
  • over_time_limit:
    • 잡이 할당 시간 초과 시 자동 종료로 자원 회수
  • 잡 배열 의존성:
    • sbatch --dependency 옵션 적극 활용, 의존성 체인 내에서 GPU/CPU 자원 할당이 꼬이지 않게 설계

종합 설계·검증 절차

  1. 현 상태 파악: sdiag, sprio, sshare 등으로 병목·불균형 원인 진단
  2. TRESBillingWeights/QOS/GrpTRES/프리엠션 정책 설계: GPU, CPU 자원별로 팀·QOS별 제한/가중치 세밀 조정
  3. 백필 파라미터 튜닝: bf_max_job_user, bf_window, bf_yield_interval 실험적으로 조정, sdiag로 효과 모니터링
  4. 우선순위/페어셰어 실시간 모니터링 체계 구축: sprio, sshare, sdiag + 필요시 GUI 도입
  5. 잡 제출/프리엠션 시나리오 테스트: 실제 잡 배열, 의존성, 프리엠션 상황별로 시뮬레이션
  6. 운영 중 지속 모니터링 및 피드백: 주기적으로 파라미터 재점검, 팀/사용자 피드백 반영

참고 자료

추가 질문이나 실제 config 샘플이 필요하시면 언제든 말씀해 주세요!
실제 운영 경험에서 자주 겪는 문제라, 팀/잡 유형/운영 정책에 맞는 맞춤형 조정이 매우 중요합니다.

9

slurm에 대해서 간간히 눈에 띄네요. :slight_smile:

11

안녕하세요.
굉장히 어려운 질문이네요. 솔직히 잡의 특성을 정확히 모르는 상태에서는 쉽게 답변하지 못할 듯 합니다.
그런데 근본적인 질문이 있습니다.
이런 실험을 하려면 잡의 특성이 일정하고 충분한 기간 동안 측정해야 정확한 결과가 나옵니다.
그런데 실제 운영중인 클러스터에서 이런 실험을 자유롭게 하지 못할 수도 있습니다.
파라미터 조정으로 인해 손해보는 잡들이 있으면 민원이 속출할 것 같고요,
어떤 기관에서 근무하시는지는 모르겠지만 특정 사이트는 잡이 몰릴 때가 있고 한가할 때도 있고 어떤 시기에 측정하는지에 따라 다 다를 것이고요.
그래서 Slurm 시뮬레이터라는 것을 추천합니다.

물론 이쪽 분야가 그럴 듯 한번에 잘 설치가 되지는 못할 것 같습니다.
그리고 질문과는 상관없지만 버전이 좀 낮긴 하네요

4 Likes