SLURM Kullanım Kılavuzu: İş Gönderme, İzleme ve Kaynak Yönetimi — Mevasis — HPC Çözümleri

SLURM (Simple Linux Utility for Resource Management), dünyadaki HPC cluster’larının büyük çoğunluğunda kullanılan açık kaynaklı iş zamanlayıcısıdır. TOP500 listesindeki sistemlerin %60’ından fazlasında SLURM çalışmaktadır. Bu rehberde temel komutlardan job script yazımına, partition yönetiminden hata ayıklamaya kadar geniş bir kapsam sunuyoruz.

SLURM Mimarisi: Kısaca Nasıl Çalışır?

SLURM üç temel bileşenden oluşur:

slurmctld (Controller Daemon): Merkezi zamanlama kararlarını verir, iş kuyruklarını yönetir
slurmd (Node Daemon): Her hesaplama node’unda çalışır, işleri başlatır ve izler
slurmdbd (Database Daemon): Hesap bilgilerini, iş geçmişini ve muhasebe verilerini saklar

Bir iş gönderdiğinizde sbatch komutu işi kuyruğa alır, slurmctld uygun node’ları rezerve eder ve slurmd işi başlatır.

Temel Komutlar Referansı

İş Gönderme

# Batch iş gönderme
sbatch myjob.sh

# Betik olmadan satır içi parametrelerle
sbatch --ntasks=8 --time=02:00:00 --mem=32G --wrap="python train.py"

# Etkileşimli oturum açma
srun --ntasks=4 --time=01:00:00 --pty bash

# GPU tahsisi ile etkileşimli oturum
srun --partition=gpu --gres=gpu:h100:2 --ntasks=1 --pty bash

İş Durumu İzleme

squeue                          # Tüm kuyruk
squeue -u $USER                 # Kendi işleriniz
squeue -j <job_id>              # Belirli bir iş
squeue -p gpu                   # Belirli partition
squeue --format="%i %j %T %R"  # Özel format: ID, isim, durum, neden

scontrol show job <job_id>      # Detaylı iş bilgisi
sinfo                           # Cluster durumu
sinfo -p compute                # Belirli partition durumu

İptal ve Kontrol

scancel <job_id>               # Belirli işi iptal et
scancel -u $USER               # Tüm işlerinizi iptal et
scancel -u $USER -t PENDING    # Yalnızca bekleyen işleri iptal et
scontrol hold <job_id>         # İşi askıya al
scontrol release <job_id>      # Askıyı kaldır

Muhasebe ve Raporlama

sacct -j <job_id>
sacct -j <job_id> --format=JobID,JobName,State,CPUTime,MaxRSS,Elapsed
sacct -u $USER --starttime=2026-01-01 --format=JobID,State,Elapsed
sreport cluster utilization start=2026-01-01 end=2026-04-01

Job Script Yazımı: Temel Yapı

SLURM job script’leri #SBATCH direktifleriyle parametre belirterek çalışır. İşte temel bir şablon:

#!/bin/bash
#SBATCH --job-name=my_simulation      # İş adı
#SBATCH --output=logs/%j.out          # Stdout: %j job ID
#SBATCH --error=logs/%j.err           # Stderr
#SBATCH --partition=compute           # Partition adı
#SBATCH --nodes=4                     # Node sayısı
#SBATCH --ntasks-per-node=64          # Node başına görev
#SBATCH --cpus-per-task=1             # Görev başına CPU
#SBATCH --mem=256G                    # Node başına bellek
#SBATCH --time=12:00:00               # Maksimum süre (SS:DD:SS)
#SBATCH --mail-type=END,FAIL          # E-posta bildirimi
#SBATCH --mail-user=kullanici@kurum.edu

# Ortam hazırlığı
module load openmpi/4.1.5 gcc/12.3

# Çalışma dizini log
echo "Job ID: $SLURM_JOB_ID"
echo "Nodes: $SLURM_JOB_NODELIST"
echo "Start: $(date)"

# MPI ile çalıştırma
srun ./my_mpi_program input.dat

echo "End: $(date)"

GPU İş Scriptleri

GPU iş yükleri için ek direktifler gerekir:

#!/bin/bash
#SBATCH --job-name=deep_learning
#SBATCH --partition=gpu
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=4       # Node başına GPU sayısı kadar görev
#SBATCH --gres=gpu:h100:4         # Node başına 4× H100 GPU
#SBATCH --cpus-per-task=16        # GPU başına 16 CPU
#SBATCH --mem=320G
#SBATCH --time=48:00:00

module load cuda/12.3 pytorch/2.2

# Çoklu node DDP (DistributedDataParallel) eğitimi
export MASTER_ADDR=$(scontrol show hostnames "$SLURM_JOB_NODELIST" | head -n1)
export MASTER_PORT=12355

srun python -m torch.distributed.run \
    --nproc_per_node=4 \
    --nnodes=$SLURM_NNODES \
    --node_rank=$SLURM_NODEID \
    --master_addr=$MASTER_ADDR \
    --master_port=$MASTER_PORT \
    train.py --epochs 100 --batch-size 256

Array Jobs: Parametre Tarama

Parametrik çalışmalar için job array’ler verimliliği önemli ölçüde artırır:

#!/bin/bash
#SBATCH --job-name=param_sweep
#SBATCH --array=1-100             # 100 farklı parametre seti
#SBATCH --array=1-100%10          # Aynı anda en fazla 10 çalıştır
#SBATCH --ntasks=8
#SBATCH --mem=32G
#SBATCH --time=02:00:00

# Her görev kendi parametre satırını okur
PARAM=$(sed -n "${SLURM_ARRAY_TASK_ID}p" parameters.txt)

srun ./simulation --param $PARAM --output results/run_${SLURM_ARRAY_TASK_ID}.dat

Job array’ler scheduler üzerindeki yükü tek tek iş göndermeye göre dramatik biçimde azaltır.

Bağımlılık Zinciri: İş Akışı Yönetimi

İşler arasında bağımlılık tanımlamak mümkündür:

# 1. aşama: veri hazırlama
jid1=$(sbatch --parsable preprocess.sh)

# 2. aşama: yalnızca 1. başarıyla tamamlandıysa çalış
jid2=$(sbatch --parsable --dependency=afterok:$jid1 simulate.sh)

# 3. aşama: analiz
sbatch --dependency=afterok:$jid2 analyze.sh

Bağımlılık tipleri:

Tip	Anlam
`afterok`	Bağımlı iş başarıyla tamamlandıktan sonra
`afternotok`	Bağımlı iş başarısız olduktan sonra
`afterany`	Her koşulda, bağımlı iş bittikten sonra
`after`	Bağımlı iş başladıktan sonra

Partition ve QOS Yönetimi

Cluster yöneticileri farklı iş tipleri için partition’lar tanımlar:

sinfo -o "%P %D %C %l"   # Partition adı, node sayısı, CPU durumu, max süre

Örnek partition yapısı:

Partition	Amaç	Maks Süre	Öncelik
`debug`	Kısa test işleri	1 saat	Yüksek
`compute`	Genel CPU iş yükleri	72 saat	Normal
`gpu`	GPU hesaplama	48 saat	Normal
`bigmem`	Büyük bellek iş yükleri	24 saat	Normal
`long`	Uzun süreli simülasyonlar	7 gün	Düşük

Kaynak Kullanım Optimizasyonu

Bellek Doğru Tahsisi

Fazla bellek talep etmek sizi dezavantajlı konuma sokar: daha az node’a yerleşir, daha uzun beklersiniz.

# Gerçek bellek kullanımını öğren
sacct -j <job_id> --format=MaxRSS

# Bir sonraki çalışmada MaxRSS × 1.2 + 10% güvenlik marjı ile iste

CPU Binding

NUMA mimarisinde CPU binding performansı artırır:

#SBATCH --cpu-bind=cores    # CPU'ları çekirdeğe bağla
#SBATCH --hint=nomultithread  # SMT/HyperThreading devre dışı

Checkpointing

Uzun işlerde periyodik kontrol noktası kritik önem taşır:

# DMTCP ile checkpoint
dmtcp_launch --interval 3600 ./my_program   # Saatte bir
dmtcp_restart ./dmtcp_restart_script.sh     # Yeniden başlatma

Yaygın Hatalar ve Çözümleri

İş Neden PENDING Durumunda Kalıyor?

squeue -j <job_id> -o "%R"   # Beklenme sebebi

Yaygın sebepler:

Reason	Anlam ve Çözüm
`Resources`	Yeterli kaynak yok; daha az kaynak iste veya bekle
`Priority`	Öncelik düşük; daha kritik işler sıradan önce
`QOSMaxJobsPerUser`	Kullanıcı iş sınırına ulaşıldı
`ReqNodeNotAvail`	İstenen node bakımda; partition değiştir
`DependencyNeverSatisfied`	Bağımlılık sağlanamadı; bağımlı işi incele

Bellek Hatası (OOM Killed)

# Kontrol et
sacct -j <job_id> --format=State,ExitCode,MaxRSS
# ExitCode 137 veya State=OUT_OF_MEMORY → bellek yetersiz
# Çözüm: --mem değerini artır

MPI Başlatma Sorunları

# srun yerine mpirun kullanıldıysa SLURM entegrasyonu sorunlu olabilir
# SLURM için srun tercih et:
srun --mpi=pmix ./my_mpi_program

Pratik İpuçları

Dry run ile önce test et:

sbatch --test-only myjob.sh   # Gerçekten göndermeden tahmini başlangıç zamanı göster

İş çıktısını canlı izle:

tail -f logs/${SLURM_JOB_ID}.out

Cluster kullanım oranını gör:

sinfo -o "%n %C" | awk '{split($2,a,"/"); print $1, a[2]-a[1], "boş"}'

Mevasis HPC Eğitim Hizmetleri

SLURM yönetimi, job script optimizasyonu ve HPC yazılım stack kurulumu konularında Mevasis HPC Eğitim hizmetlerimizden yararlanabilirsiniz. Ekibimiz hem cluster yöneticilerine hem de son kullanıcılara özel program sunmaktadır.

Sıkça Sorulan Sorular

SLURM mu PBS/Torque mi kullanmalıyım? Yeni kurulumlar için SLURM tercih edilir. Aktif geliştirme, geniş topluluk ve iyi bulut entegrasyonu ile SLURM fiilî standart konumundadır. Mevcut PBS kurulumları için geçiş genellikle 6–12 aylık proje gerektirir.

Job script olmadan tek komut nasıl gönderilir? sbatch --wrap="komut" veya srun komut kullanılabilir. Tekrarlanan işler için job script tercih edilmeli; reproducibility ve hata ayıklama kolaylığı sağlar.

Kaç node’da ölçeklendirebilirsiniz? SLURM teorik olarak 100.000+ node ölçeğinde çalışır. Pratik sınır genellikle ağ yapısı ve dosya sistemi performansıdır; bant genişliği doyduğunda MPI verimliliği düşer.

Jupyter Notebook SLURM üzerinde nasıl çalıştırılır? Compute node üzerinde Jupyter Server başlatıp port yönlendirme ile login node üzerinden erişilebilir. Open OnDemand platformu bu süreci arayüz üzerinden yönetmeyi sağlar.

SLURM accountware muhasebe sistemi nedir? sacct/sreport komutları ile CPU saat, GPU saat ve bellek kullanımı proje ve kullanıcı bazında raporlanabilir. Araştırma merkezlerinde fatura ve kaynak tahsis kararları bu verilere dayanır.