Slurm Performans Optimizasyonu: 5 Kritik Ayar

Slurm kurulumu yapıldıktan sonra işler çalışıyor olabilir — ama gerçekten verimli çalışıyor mu? Çoğu HPC kümesi, varsayılan Slurm yapılandırmasıyla çalıştırıldığında potansiyelinin ancak %60-70’ini kullanır. İşte kurumsal HPC ortamlarında yıllar içinde edindiğimiz tecrübeyle belirlediğimiz, Slüm performansını dramatik ölçüde artıran 5 kritik yapılandırma ayarı.

Bu optimizasyonlar, Slurm HPC küme yönetimi rehberimizin tamamlayıcısı niteliğindedir. Temel mimari ve kurulum bilgisi için kapsamlı Slurm rehberimizi okumanızı öneririz.

1. Backfill Scheduling ile Kaynak Kullanımını Maksimize Edin

Backfill scheduling, Slurm’ün en güçlü özelliklerinden biridir ve çoğu kümede ya kapalıdır ya da yanlış yapılandırılmıştır. Bu mekanizma, yüksek öncelikli büyük işler için kaynak rezerve ederken, bu kaynaklar boşta kaldığı sürece küçük işlerin çalıştırılmasına izin verir.

# slurm.conf — Backfill optimizasyonu
SchedulerType=sched/backfill
bf_interval=30
bf_max_job_test=200
bf_resolution=60
bf_window=1440

Bu ayarlar ne işe yarar:

• bf_interval=30: Her 30 saniyede bir backfill penceresi değerlendirilir. Çok sık yapılandırılırsa controller CPU’su gereksiz meşgul olur; çok seyrek yapılandırılırsa küçük işler gereksiz bekler. 30 saniye, çoğu küme için optimaldir.
• bf_max_job_test=200: Backfill penceresinde test edilecek maksimum iş sayısı. 200-500 arası değerler büyük kümelerde iyi çalışır.
• bf_window=1440: Backfill penceresi dakika cinsinden (1440 = 24 saat). Bu pencere içinde başlayabilecek küçük işler, büyük iş rezervasyonunu engellemeden çalıştırılır.

2. Partition Optimizasyonu: İş Karışımını Dengeleyin

Tek bir partition’da tüm işleri çalıştırmak, Slurm performans optimizasyonunun en büyük düşmanıdır. İş profillerine göre ayrıştırılmış partition yapısı, hem kullanıcı deneyimini hem de küme verimliliğini artırır.

# Optimize edilmiş partition yapılandırması
PartitionName=short   Nodes=cn[01-20] MaxTime=04:00:00 Default=YES \
    Priority=200 MaxNodes=8

PartitionName=long    Nodes=cn[01-20] MaxTime=7-00:00:00 \
    Priority=100 MaxNodes=32

PartitionName=gpu     Nodes=gpu[01-04] MaxTime=48:00:00 \
    Priority=300 TRESBillingWeights="CPU=1,GRES/gpu=32"

PartitionName=debug   Nodes=cn01       MaxTime=00:30:00 MaxNodes=1 \
    Priority=500 State=UP

Kritik parametreler:

• Priority: Debug partition en yüksek, GPU ikinci — böylece test ve GPU işleri hemen başlar
• MaxNodes: Short partition’da 8 düğüm limiti, büyük işlerin short kuyruğu tıkamasını engeller
• TRESBillingWeights: GPU partition’ında GPU kullanımı CPU’ya göre 32 kat daha ağır faturalandırılır — doğru muhasebe için şart

3. Cgroup Bellek Yönetimi: OOM Cinayetlerini Engelleyin

Varsayılan cgroup yapılandırması genellikle sadece CPU kısıtlaması içerir. Bellek yönetimi olmadan, tek bir hatalı iş tüm düğümü çökertebilir.

# /etc/slurm/cgroup.conf — Agresif bellek yönetimi
CgroupAutomount=yes
ConstrainCores=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
ConstrainDevices=yes
AllowedSwapSpace=0
MaxRAMPercent=98
MinRAMSpace=2048

Neden bu değerler:

• AllowedSwapSpace=0: HPC iş yüklerinde swap kullanımı performansı felç eder. İşleri swap kullandırmak yerine OOM kill ile sonlandırmak, düğümün diğer işlerini korur.
• MaxRAMPercent=98: Düğüm belleğinin %98’inden fazlasını Slurm işlerine tahsis etme. Kalan %2 işletim sistemi ve slurmd için ayrılır.
• MinRAMSpace=2048: Her düğümde en az 2GB boş bellek bırak — işletim sistemi kararlılığı için kritik.

4. GPU GRES Optimizasyonu: Maksimum GPU Verimi

GPU zamanlamasında en sık yapılan hata, tüm GPU’ları tek bir havuzda toplamaktır. Heterojen GPU’ları (A100, H100, L40S) doğru tiplendirmek ve MIG (Multi-Instance GPU) desteğini etkinleştirmek, GPU kullanım oranını %40’lardan %85+ seviyesine çıkarabilir.

# gres.conf — Heterojen GPU yapılandırması
NodeName=gpu01 Name=gpu Type=h100 File=/dev/nvidia[0-7] Count=8
NodeName=gpu02 Name=gpu Type=a100 File=/dev/nvidia[0-3] Count=4
NodeName=gpu03 Name=gpu Type=l40s File=/dev/nvidia[0-7] Count=8

# slurm.conf — MIG desteği
GresTypes=gpu

# Kullanıcı tarafında: doğru GPU tipini talep etme
#SBATCH --gres=gpu:h100:2    # H100 için
#SBATCH --gres=gpu:l40s:1    # L40S için (inference)

5. slurmdbd Veritabanı Optimizasyonu

Büyük kümelerde (500+ kullanıcı, günde 10.000+ iş) slurmdbd veritabanı performansı darboğaz oluşturabilir. Özellikle sacct ve sreport sorguları yavaşladığında kullanıcılar şikayet etmeye başlar.

-- MySQL/MariaDB optimizasyonları
ALTER TABLE cluster_event_table ADD INDEX idx_time (time_end);
ALTER TABLE cluster_job_table ADD INDEX idx_user (id_user, time_end);
ALTER TABLE cluster_step_table ADD INDEX idx_job (id_job);

# slurmdbd.conf — Performans ayarları
ArchiveEvents=yes
ArchiveJobs=yes
ArchiveSteps=yes
ArchiveScript=./archive_slurmdb.sh
PurgeEventAfter=6months
PurgeJobAfter=12months

Arşivleme stratejisi: 6 aydan eski olayları ve 12 aydan eski iş kayıtlarını arşivleyin — canlı veritabanı boyutunu kontrol altında tutar, sorgu performansını korur. Arşivlenen verilere ihtiyaç duyulduğunda ayrı bir analitik veritabanından sorgulanabilir.

Optimizasyonların Birlikte Çalışması

Bu beş optimizasyon tek başına değil, birlikte uygulandığında en iyi sonucu verir. Tipik bir kurumsal kümede bu ayarlar sonrası gözlemlediğimiz iyileşmeler:

• Kuyruk bekleme süresi: %40-60 azalma
• GPU kullanım oranı: %40 → %85+
• OOM kaynaklı iş başarısızlığı: %90 azalma
• Gece ve hafta sonu kullanımı: Backfill sayesinde %30 artış

Mevasis olarak kurumsal Slurm performans optimizasyonu hizmetimiz kapsamında, kümenizin mevcut yapılandırmasını analiz ediyor ve iş yükü profilinize özel optimizasyon planı sunuyoruz. Slurm Hizmetleri sayfamızdan veya ücretsiz keşif görüşmesi ile bize ulaşabilirsiniz.

Performans Optimizasyonunda Sık Yapılan Hatalar

Yıllar içinde kurumsal Slurm optimizasyon projelerinde en sık karşılaştığımız hataları ve bunlardan kaçınma yollarını paylaşıyoruz:

Hata 1: Tüm partition’larda aynı öncelik seviyesini kullanmak Tüm partition’lar aynı PriorityWeight değerine sahip olduğunda, Slurm işleri FIFO sırasına göre zamanlar — bu da kısa test işlerinin bile büyük simülasyonların arkasında saatlerce beklemesine neden olur. Her partition için farklı Priority değeri atayın.

Hata 2: Cgroup yapılandırmasını atlamak Cgroup olmadan çalışan Slurm, bir nevi emniyet kemeri olmayan araba kullanmak gibidir. Bellek kısıtlaması olmayan bir düğümde, tek bir hatalı iş tüm kullanıcıların işlerini çökertebilir. ConstrainRAMSpace=yes her zaman açık olmalıdır.

Hata 3: Backfill scheduling’i yanlış yapılandırmak bf_window değerini çok yüksek (örneğin 7 gün) ayarlamak, Slurm controller’ının gereksiz yere binlerce işi sürekli test etmesine neden olur. 24-48 saat arası bir pencere çoğu küme için idealdir.

Hata 4: GPU’ları homojen varsaymak A100 ve H100 GPU’ları aynı gres.conf girdisinde Type=gpu olarak tanımlamak, kullanıcıların yanlışlıkla H100 talep edip A100 almasına (veya tam tersi) neden olur. Her GPU modeli için ayrı Type tanımlayın: Type=h100, Type=a100.

Hata 5: Veritabanı bakımını ihmal etmek Aylık OPTIMIZE TABLE ve düzenli arşivleme yapılmayan slurmdbd veritabanları, 6-12 ay içinde sacct sorgularının 10-30 saniye sürmesine neden olacak kadar şişer.

Bu hatalardan kaçınmak ve Slurm performans optimizasyonunuzu profesyonelce yönetmek için Slurm Hizmetleri sayfamızı ziyaret edin.