Scheduling Algorithms (Admin Guide)

Unfortunately, this article is currently only available in German but will be translated soon.

Problemstellung

SLURM bietet eine Vielzahl an Konfigurationsmöglichkeiten, um auf verschiedene Art und Weise das Schedulen von Jobs zu beeinflussen. Die Anzahl an Parameters ist zunächst einmal etwas überwältigend. Daher sollen diese hier etwas erläutert werden und was in Aachen warum gesetzt wurde.

Scheduling Algorithmen

SchedulerType

• sched/builtin - der Standard FIFO Scheduler von SLURM, wobei FIFO hier die Prioritäten meint, als höchste Priorität ist first, niedrigste last
• sched/hold - wie builtin, aber alle neuen Jobs werden auf hold gesetzt, wenn die Datei “/etc/slurm.hold” existiert
• sched/backfill - In Aachen eingesetzt, da der Scheduler hier versucht Tetris zu spielen, also Lücken aufzufüllen die z.B. “vor” großen Jobs entstehen.
  • Slurm scheduling Configuration Guide

SelectType

• select/serial - “No” HPC but HTC, just serial jobs
• select/cray - For sites with a CRAY system
• select/linear - For BIG Sites, e.g. Research Center Jülich, just node wise scheduling
  • pro : Erheblich geringerer Scheduling Aufwand
  • contra : Viel Verschnitt, z.B. serielle Jobs auf 48 Core Knoten
• select/cons_tres - ab SLURM 19.05, wird select/cons_res zukünftig ersetzen, auch GPUs sind jetzt consumable resources, keine generic resources mehr
• select/cons_res - CPU und Speicher sind “Consumable Resources”, Rechenknoten können zwischen Jobs geshared werden, das Setup in Aachen