slurm 작업 oversubscribe 활성화, max job 수 증가

[jhgoh]

유저 잡이 전체 노드를 사용하지 않고 있는 것으로 확인하여 최대 노드 수를 사용하도록 설정함.
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_BIND mask 직접 디코딩으로 서로 다른 두 잡이 같은 물리 코어의 형제 스레드를 나눠 쓰는 것을 실증.
• 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로 정정.

[jhgoh]

#136

[jhgoh]

MaxArraySize=10000
MaxJobCount=100000

으로 증가시킴.

[jhgoh]

Oversubscribe가 의도한대로 동작하지 않고 한 CPU를 두 process가 경쟁하는 방식으로 동작중으로, 절반 CPU는 0%로 나타나고 있음.

[jhgoh]

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)
• 이 하드웨어(AMD, split-half SMT)는 형제 스레드가 N과 N+64 쌍인데, 128개 잡 전체를 확인한 결과 실제로는 딱 64개의 스레드(063)에만 2개씩 몰려있고 형제 스레드(64127)는 전혀 쓰이지 않고 있었음 → 노드 연산 능력의 절반을 그냥 낭비하고 있던 상황
• slurm.conf의 토폴로지 설정(CPUs=128, ThreadsPerCore=2 등)은 slurmd -C의 자동 감지값과 정확히 일치 → 설정 값 자체는 문제 없었음
• 원인은 TaskPlugin=task/affinity의 기본 바인딩이 코어 단위로 동작하면서, 오버서브스크립션된 두 번째 잡을 실제 형제 스레드(+64)가 아니라 같은 스레드에 재배치하고 있었던 것

조치

slurm.conf에 추가:

TaskPluginParam=Threads

전체 노드에 배포 후 scontrol reconfigure.

검증

설정 반영 이후 새로 제출한 테스트 잡은 Cpus_allowed_list가 24,88처럼 실제 형제 스레드 쌍 전체로 잡히는 것을 확인 (24 + 64 = 88). 커널 스케줄러가 둘 중 비어있는 스레드로 자동 분산 배치 가능해짐.

참고

• 이미 실행 중이던 잡은 시작 시점에 cgroup affinity가 고정되므로 이번 수정이 적용되지 않음 — 새로 제출되는 잡부터 적용됨. 기존 잡을 죽였다 다시 낼 필요는 없음.
• scontrol show job -d의 CPU_IDs 필드는 실제 머신 CPU 번호와 다를 수 있으므로, 실제 바인딩 확인은 항상 /proc/<pid>/status의 Cpus_allowed_list로 할 것.

[jhgoh]

실제로 SMT가 제대로 반영되지 않고 있는 것으로 확인됨. TaskPlugin을 수정해 해결함. 아래는 클로드 요약:

CPU 바인딩 문제 최종 정리 (이전 댓글 정정)

⚠️ 이전 댓글에서 TaskPluginParam=Threads로 해결했다고 적었으나 틀린 내용이었음. 아래가 실제 원인과 최종 조치.

증상

normal 파티션 노드(entei 등)에서 CPU 063만 100%, 64127은 0%. rat 프로세스는 각각 CPU 50%로 고정.

원인

• 이 노드들은 AMD split-half SMT 구조: CPU N과 N+64가 같은 물리 코어의 형제 스레드 (lscpu -e로 확인)
• Slurm은 ThreadsPerCore=2라서 1-CPU 잡에도 물리 코어 하나(형제 스레드 둘)를 통째로 할당함. Oversubscribe=FORCE:2로 두 잡이 한 코어를 공유 → 노드당 128잡 (64코어 × 2)
• 그런데 task/affinity가 잡마다 따로 코어의 첫 스레드(c)에만 바인딩 → 한 코어를 공유하는 두 잡이 같은 스레드 c에서 번갈아 실행되고 c+64는 유휴
• scontrol show job -d의 CPU_IDs는 Slurm 내부(abstract) 번호라 실제와 다름 (abstract 2c, 2c+1 = 실제 c, c+64). 실제 바인딩은 /proc/<pid>/status의 Cpus_allowed_list로 확인해야 함

이전 조치가 안 됐던 이유

• TaskPluginParam=Threads는 태스크를 스레드 하나에 바인딩하는 설정이라, 오히려 증상을 그대로 재현함
• 게다가 TaskPlugin 관련 설정은 scontrol reconfigure로 반영되지 않고 slurmd 재시작이 필요함. entei의 slurmd가 9/11부터 계속 떠 있어서 9/27 변경은 적용된 적이 없었음

최종 조치

slurm.conf:

TaskPlugin=task/cgroup
# TaskPluginParam=Threads  → 삭제

• task/affinity 제거. cgroup.conf의 ConstrainCores=yes는 유지
• 잡은 자기 코어(c, c+64) 밖으로 못 나가고, 코어 안에서는 커널이 두 잡을 두 스레드에 나눠 배치
• 컨트롤러 반영 후 각 노드 slurmd 재시작 (실행 중인 잡은 영향 없음)

검증

• lapras에서 1-CPU 테스트 잡: Cpus_allowed_list가 0,64, 1,65 (코어 통째)
• taskset -c 5,69로 yes 두 개 실행: 5번과 69번으로 갈라져서 둘 다 100%
• raikou에서 기존 잡과 코어를 공유하도록 테스트 array 8개 투입: 전부 c,c+64 마스크, CPU 약 100%, 대부분 c+64에서 실행 (짝인 기존 잡이 c에 묶여 있어서 비켜 감)
• entei htop에서 64~127번이 점차 켜지고 CPU 사용량 상승 중

참고

• 이미 떠 있던 잡은 옛 바인딩을 유지하고, 끝나면서 자연스럽게 전환됨
• nproc은 2로 보임 (코어 하나 = 스레드 둘). 스레드 수를 nproc으로 정하는 코드는 짝 잡의 스레드까지 가져갈 수 있음. 현재 워크로드(rat)는 싱글스레드라 영향 없음
• 대시보드 CPU%는 논리 CPU 기준이라 50% → 100%가 처리량 2배를 뜻하지 않음. 실제 이득은 SMT 이득만큼 (보통 10~30%)
• sinfo의 alloc 표시는 FORCE:2의 두 번째 칸이 비었는지 보여주지 않음. "alloc"이어도 잡이 들어갈 수 있음

[jhgoh]

잘 적용되어서 CPU사용량도 충분히 올라가는 것으로 보임.