View source for Admin Guide Scheduling Algorithms

[[Category:HPC-Admin|Scheduling Algorithms]]<nowiki />
[[Category:HPC.NRW-Best-Practices|Scheduling Algorithms]]<nowiki />
[[Category:Slurm]]<nowiki />
{{DISPLAYTITLE:Scheduling Algorithms (Admin Guide)}}<nowiki />

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 [https://slurm.schedmd.com/priority_multifactor.html 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 und Köln eingesetzt, da der Scheduler hier versucht Tetris zu spielen, also Lücken aufzufüllen die z.B. “vor” großen Jobs entstehen.
** [https://slurm.schedmd.com/sched_config.html Slurm scheduling Configuration Guide]

[[File:Scheduler-Tetris.png|500px|Scheduler-Tetris]]

== SelectType ==

* select/serial - “No” HPC but HTC, just serial jobs
* select/cray - For sites with a [https://slurm.schedmd.com/cray.html 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

== Main- und Backfilling-Scheduler ==

=== Main Scheduler ===

Selbst wenn der Backfilling Scheduler mittels <code>sched/backfill</code>  ausgewählt wird, so verrichtet der "Main Scheduler" immer noch seinen Dienst:

* sehr schnell mit einfacher Zuweisungslogik, z.B. bei leeren Knoten,  Laufzeit höchstens ein paar Sekunden
* scannt nacheinander alle Partitionen und bricht jeweils beim ersten Zuweisungsproblem (Job bleibt im Pending Zustand) einer Partition ab 
* analog bei Job Arrays: nach der ersten nicht zuweisbaren Instanz werden keine weiteren Instanzen des Arrays betrachtet
* event-triggered: versucht bei bestimmten events zu schedulen, z.B. direkt nach Job Submit oder nach Job Beendingung (siehe <code>defer</code>) aber kann bestimmte Zeit zwischen Aufrufen warten (siehe <code>sched_min_interval</code>), checkt dabei höchstens <code>default_queue_depth</code>  pending Jobs
* interval-triggered: unabhängig von den events wird die gesamte queue (alle pending Jobs) in bestimmten Intervallen (<code>sched_interval</code>) gescannt
* in den logs erkennbar an der Meldung: <code>sched: Allocate JobId=...</code>
* wichtige Parameter:
** <code>defer</code>: jobs werden nicht mehr einzeln, direkt nach Submission, sondern später, in Gruppen, zugewiesen. Hilfreich wenn (manchmal) Hunderte von Jobs gleichzeitig submittiert werden. Erhöht Server Responsiveness zum Preis einer geringfügig verschobenen Zuweisung
** <code>sched_min_interval</code>: erzwingt Wartezeit zwischen Aufrufen. Wie bei <code>defer</code> wird damit Responsiveness erhöht. Default: 2us, in Köln: 2sec
** <code>sched_interval</code>: alle pending Jobs werden gescannt, der default von 60sec ist sinnvoll 
** <code>default_queue_depth</code>:  anzahl pending Jobs die beim trigger-event gecheckt werden, default: 100, in Köln: 300

=== Backfilling Scheduler ===

* langsam, umfassende Zuweisungslogik, je nach Config/Jobmix kann die Laufzeit auch Minuten dauern
* kann Jobs mit niedriger Priorität zuweisen, falls dadurch höher priorisierte Jobs nicht beeinflusst werden (das können Top-Nutzer mit niedrigem FairShare ausnutzen indem sie viele sehr kleine Jobs submittieren)
* interval-triggered: läuft im starren Zeitintervall (siehe <code>bf_interval</code>) 
* in den logs erkennbar an der Meldung: <code>backfill: Started JobId=...</code>
* Parameter können die Laufzeit stark beeinflussen, hier die wichtigen:
** <code>bf_window</code>: Planungshorizont, sollte mindestens so lang wie die längste erlaubte Laufzeit sein (default: 1 Tag, Köln: 30 Tage), je grösser der Horizont desto grösser der Overhead sowie die Laufzeit und entspr. schlechtere Responsiveness
** <code>bf_resolution</code>: Planungsgenauigkeit, bei grossen Planungshorizont muss sie entspr. verringert werden (default: 1 Min, Köln: 30 Min), je ungenauer bzw. grösser, desto bessere Responsiveness
** <code>bf_busy_nodes</code>: weist Jobs den Knoten zu, die bereits belegt sind, um Fragmentierung zu verringern bzw. freie Knoten für die Jobs freizuhalten, die ganze Knoten brauchen
** <code>bf_continue</code>: der Backfiller ist so langsam, dass er manchmal unterbrochen werden muss, in dem Fall fängt er beim nächsten Aufruf wieder von vorn an. Mit dieser Option macht er da weiter wo er aufgehört hat. Vorteil: kein Starving, Nachteil: neue Jobs werden langsamer zugewiesen. Sehr sinnvoller Parameter
** <code>bf_interval</code>: bestimmt die Abstände zw. Aufrufen, sollte ein Erfahrungswert sein, nicht zu niedrig (da schlechte Responsiveness und Starving, da dies zugleich die maximale Laufzeit ist), auch nicht zu hoch (interaktive Jobs warten!), default: 30sec, Köln: 2 Min
** <code>bf_max_job_user</code>:  Joblimit per Nutzer um zu vermeiden, dass ein Nutzer das Scheduling einer Iteration dominiert, default: keiner, Köln=30 Jobs
** <code>max_rpc_cnt</code>: wichtig für Responsiveness. Bei <code>max_rpc_cnt</code> aktiven Serverthreads legt der Backfiller eine Pause ein um anderen RPC Anfragen eine Chance zu geben. Ein Erfahrungswert, muss niedrig genug sein damit der Server schnell reagieren kann und hoch genug um zeitnahes Scheduling zu ermöglichen.