slurm 작업 oversubscribe 활성화, max job 수 증가 #138
Description
유저 잡이 전체 노드를 사용하지 않고 있는 것으로 확인하여 최대 노드 수를 사용하도록 설정함.
HPC에서는 일반적으로 최대 performance를 위해 물리 CPU를 서로 다른 task간 공유하지 않는 것을 기본으로 하지만, 현재 실행하는 대부분의 job들은 HPC잡보다는 HTC잡에 가까우므로 SMT에서 잡 두 개씩 돌도록 할 것임.
아래는 claude가 정리한 내용:
배경
normal 파티션(raikou, entei, suicune, ho-oh, 총 448 CPU)에서 유저들이 제출한 단일 코어 잡이 논리 CPU의 절반밖에 못 쓰는 현상 발견. sinfo상으로는 CPU가 여유 있는데도 새 잡이 Resources로 대기하는 경우가 반복됨.
원인 분석
SLURM_HINT=nomultithread가 기본값이라 기본적으로 SMT(하이퍼스레딩) 절반을 안 씀 →SLURM_HINT=multithread를/etc/profile.d/로 클러스터 기본값으로 배포, 유저별 override는 가능하게 유지.- 위 조치 이후에도 여전히 코어 활용이 반쪽: Slurm은 기본적으로 서로 다른 잡(job) 간에는 물리 코어를 공유하지 않음 (SchedMD FAQ 확인). 즉 독립적인 1-cpu 잡들을 여러 개 돌려도 각 잡이 물리 코어 하나씩(형제 스레드 포함)을 통째로 점유해버려서, 전체 논리 CPU의 절반만 실제로 채워짐.
- 이 클러스터는 Condor/PBS 스타일(독립적인 단일 스레드 잡들이 아무 논리 CPU나 자유롭게 채움)을 기대하는 워크로드가 대부분이라, Slurm의 기본 코어-배타 정책과 안 맞음.
해결 방법
파티션의 OverSubscribe 파라미터로 코어 공유를 강제 허용:
OverSubscribe=FORCE:2: 물리 코어당 2개 스레드(ThreadsPerCore=2)까지 서로 다른 잡이 나눠 쓰도록 강제. 유저 스크립트 수정 불필요하지만--exclusive옵션은 거부됨(opt-out 불가).OverSubscribe=YES:N: 유저가--oversubscribe로 opt-in해야 공유됨 (기본은 배타).
테스트 (gpu1/lapras에서 검증)
- Threadripper 3990X, 128 threads.
OverSubscribe=FORCE:2적용 후 256-array 잡 제출 시 정확히 128개 RUNNING, 나머지 PENDING → 스레드 단위로 꽉 채워짐 확인. SLURM_CPU_BINDmask 직접 디코딩으로 서로 다른 두 잡이 같은 물리 코어의 형제 스레드를 나눠 쓰는 것을 실증.- AMD 계열 CPU들의 SMT 형제 스레드 번호 규칙(“split-half”: CPU N ↔ CPU N+총스레드수/2) 확인:
- raikou (EPYC 9334, 128 threads): N ↔ N+64
- entei, suicune: 동일
- ho-oh (EPYC 7302, 64 threads): N ↔ N+32
- lapras (Threadripper 3990X, 128 threads): N ↔ N+64
적용 내역
normal파티션:OverSubscribe=FORCE:2적용 (기본 공유 모드).- 전용 코어가 필요한 유저를 위한
normal_excl파티션 신설 (같은 4개 노드,OverSubscribe=NO,Default=NO). 필요 시-p normal_excl로 명시 제출. /etc/slurm/slurm.conf를 hep에서 수정 후 slurmd가 도는 전 노드(raikou, entei, suicune, ho-oh, lapras, naong)에 배포 →scontrol reconfigure.- 이 클러스터는 configless 모드(
enable_configless) 미사용 → config 변경 시 매번 전체 노드에 수동 배포 필요. - 배포 중
normal/normal_excl둘 다Default=YES로 겹치는 실수 발견 →normal_excl을Default=NO로 정정.
- 이 클러스터는 configless 모드(
Activity
jhgoh commentedon Sep 27, 2026
#136
jhgoh commentedon Sep 27, 2026
으로 증가시킴.
[-]slurm 작업 oversubscribe 활성화[/-][+]slurm 작업 oversubscribe 활성화, max job 수 증가[/+]jhgoh commentedon Sep 27, 2026
Oversubscribe가 의도한대로 동작하지 않고 한 CPU를 두 process가 경쟁하는 방식으로 동작중으로, 절반 CPU는 0%로 나타나고 있음.
jhgoh commentedon Sep 27, 2026
binding문제가 있는 것으로 보임. 일단 clade 제안에 따라 설정 추가하고 적용함.
CPU 바인딩 문제 (SMT 형제 스레드 미활용) 진단 및 수정
증상
entei노드에서 여러 잡이 동시에 도는데 htop 상으로 논리 코어의 절반(063)만 100%, 나머지 절반(64127)은 계속 idle. 개별 프로세스 CPU%도 각각 ~50%로 고정.진단
scontrol show job <id> -d의CPU_IDs는 실제 머신 CPU 번호가 아니라 Slurm 내부 abstract 번호였음 (신뢰 불가) →scontrol listpids <id>로 PID 찾은 뒤/proc/<pid>/status의Cpus_allowed_list로 실제 바인딩 확인Oversubscribe=FORCE:2로 묶인 두 잡이 완전히 동일한 단일 CPU에 물려있었음 (예: 62632, 63119 둘 다Cpus_allowed_list: 0)N과N+64쌍인데, 128개 잡 전체를 확인한 결과 실제로는 딱 64개의 스레드(063)에만 2개씩 몰려있고 형제 스레드(64127)는 전혀 쓰이지 않고 있었음 → 노드 연산 능력의 절반을 그냥 낭비하고 있던 상황slurm.conf의 토폴로지 설정(CPUs=128,ThreadsPerCore=2등)은slurmd -C의 자동 감지값과 정확히 일치 → 설정 값 자체는 문제 없었음TaskPlugin=task/affinity의 기본 바인딩이 코어 단위로 동작하면서, 오버서브스크립션된 두 번째 잡을 실제 형제 스레드(+64)가 아니라 같은 스레드에 재배치하고 있었던 것조치
slurm.conf에 추가:전체 노드에 배포 후
scontrol reconfigure.검증
설정 반영 이후 새로 제출한 테스트 잡은
Cpus_allowed_list가24,88처럼 실제 형제 스레드 쌍 전체로 잡히는 것을 확인 (24 + 64 = 88). 커널 스케줄러가 둘 중 비어있는 스레드로 자동 분산 배치 가능해짐.참고
scontrol show job -d의CPU_IDs필드는 실제 머신 CPU 번호와 다를 수 있으므로, 실제 바인딩 확인은 항상/proc/<pid>/status의Cpus_allowed_list로 할 것.jhgoh commentedon Sep 29, 2026
실제로 SMT가 제대로 반영되지 않고 있는 것으로 확인됨. TaskPlugin을 수정해 해결함. 아래는 클로드 요약:
CPU 바인딩 문제 최종 정리 (이전 댓글 정정)
증상
normal파티션 노드(entei 등)에서 CPU 063만 100%, 64127은 0%.rat프로세스는 각각 CPU 50%로 고정.원인
N과N+64가 같은 물리 코어의 형제 스레드 (lscpu -e로 확인)ThreadsPerCore=2라서 1-CPU 잡에도 물리 코어 하나(형제 스레드 둘)를 통째로 할당함.Oversubscribe=FORCE:2로 두 잡이 한 코어를 공유 → 노드당 128잡 (64코어 × 2)task/affinity가 잡마다 따로 코어의 첫 스레드(c)에만 바인딩 → 한 코어를 공유하는 두 잡이 같은 스레드c에서 번갈아 실행되고c+64는 유휴scontrol show job -d의CPU_IDs는 Slurm 내부(abstract) 번호라 실제와 다름 (abstract2c, 2c+1= 실제c, c+64). 실제 바인딩은/proc/<pid>/status의Cpus_allowed_list로 확인해야 함이전 조치가 안 됐던 이유
TaskPluginParam=Threads는 태스크를 스레드 하나에 바인딩하는 설정이라, 오히려 증상을 그대로 재현함scontrol reconfigure로 반영되지 않고 slurmd 재시작이 필요함. entei의 slurmd가 9/11부터 계속 떠 있어서 9/27 변경은 적용된 적이 없었음최종 조치
slurm.conf:task/affinity제거.cgroup.conf의ConstrainCores=yes는 유지c, c+64) 밖으로 못 나가고, 코어 안에서는 커널이 두 잡을 두 스레드에 나눠 배치검증
Cpus_allowed_list가0,64,1,65(코어 통째)taskset -c 5,69로yes두 개 실행: 5번과 69번으로 갈라져서 둘 다 100%c,c+64마스크, CPU 약 100%, 대부분c+64에서 실행 (짝인 기존 잡이c에 묶여 있어서 비켜 감)참고
nproc은 2로 보임 (코어 하나 = 스레드 둘). 스레드 수를nproc으로 정하는 코드는 짝 잡의 스레드까지 가져갈 수 있음. 현재 워크로드(rat)는 싱글스레드라 영향 없음sinfo의alloc표시는FORCE:2의 두 번째 칸이 비었는지 보여주지 않음. "alloc"이어도 잡이 들어갈 수 있음jhgoh commentedon Sep 29, 2026
잘 적용되어서 CPU사용량도 충분히 올라가는 것으로 보임.