Revision as of 22:20, 29 May 2021

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 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.
- 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

Main- und Backfilling-Scheduler

Main Scheduler

Selbst wenn der Backfilling Scheduler mittels sched/backfill 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 defer) aber kann bestimmte Zeit zwischen Aufrufen warten (siehe sched_min_interval), checkt dabei höchstens default_queue_depth pending Jobs
interval-triggered: scannt die gesamte queue (alle pending Jobs) in bestimmten Intervallen (sched_interval)
in den logs erkennbar an der Meldung: sched: Allocate JobId=...
wichtige Parameter:
- defer: 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
- sched_min_interval: erzwingt Wartezeit zwischen Aufrufen. Wie bei defer: wird damit Responsiveness erhöht. Default: 2us, in Köln: 30sec
- sched_interval: alle pending Jobs werden gescannt, der default von 60sec ist sinnvoll
- default_queue_depth: 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 "ausgenutztem" FairShare ausnutzen indem sie viele sehr kleine Jobs submittieren)
interval-triggered: läuft im starren Zeitintervall (siehe bf_interval)
in den logs erkennbar an der Meldung: backfill: Started JobId=...
Parameter können die Laufzeit stark beeinflussen, hier die wichtigen:
- bf_window: 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 und schlechtere Responsiveness
- bf_resolution: Planungsgenauigkeit, bei grossen Planungshorizont muss sie entspr. verringert werden (default: 1 Min, Köln: 30 Min), je ungenauer bzw. grösser, desto bessere Responsiveness
- bf_busy_nodes: weise Jobs den Knoten zu, die bereits belegt sind, um Fragmentierung zu verringern bzw. freie Knoten für die Jobs freizuhalten, die ganze Knoten brauchen
- bf_continue: 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
- bf_interval: 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
- bf_max_job_user: Nutzerlimit um zu vermeiden, dass ein Nutzer das Scheduling einer Iteration dominiert, default: keiner, Köln=30 Jobs
- max_rpc_cnt: wichtig für Responsiveness. Bei max_rpc_cnt aktiven Serverthreads legt der Backfiller eine Pause ein um anderen RPC Anfragen eine Change zu geben

@@ Line 35: / Line 35: @@
 === Main Scheduler ===
-Selbst wenn der Backfilling Scheduler mittels ```sched/backfill``` ausgewählt wird, so verrichtet der "Main Scheduler" immer noch seinen Dienst:
+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 ```defer```) aber kann bestimmte Zeit zwischen Aufrufen warten (siehe ```sched_min_interval```), checkt dabei höchstens ```default_queue_depth``` pending Jobs
+* 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: scannt die gesamte queue (alle pending Jobs) in bestimmten Intervallen (```sched_interval```)
+* interval-triggered: scannt die gesamte queue (alle pending Jobs) in bestimmten Intervallen (<code>sched_interval</code>)
-* in den logs erkennbar an der Meldung: ```sched: Allocate JobId=...```
+* in den logs erkennbar an der Meldung: <code>sched: Allocate JobId=...</code>
 * wichtige Parameter:
-** ```defer```: 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>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
-** ```sched_min_interval```: erzwingt Wartezeit zwischen Aufrufen. Wie bei ```defer``` wird damit Responsiveness erhöht. Default: 2us, in Köln: 30sec
+** <code>sched_min_interval</code>: erzwingt Wartezeit zwischen Aufrufen. Wie bei <code>defer</code>: wird damit Responsiveness erhöht. Default: 2us, in Köln: 30sec
-** ```sched_interval```: alle pending Jobs werden gescannt, der default von 60sec ist sinnvoll
+** <code>sched_interval</code>: alle pending Jobs werden gescannt, der default von 60sec ist sinnvoll
-** ```default_queue_depth```:  anzahl pending Jobs die beim trigger-event gecheckt werden, default: 100, in Köln: 300
+** <code>default_queue_depth</code>:  anzahl pending Jobs die beim trigger-event gecheckt werden, default: 100, in Köln: 300
 === Backfilling Scheduler ===
@@ Line 53: / Line 53: @@
 * 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 "ausgenutztem" FairShare ausnutzen indem sie viele sehr kleine Jobs submittieren)
-* interval-triggered: läuft im starren Zeitintervall (siehe ```bf_interval```)
+* interval-triggered: läuft im starren Zeitintervall (siehe <code>bf_interval</code>)
-* in den logs erkennbar an der Meldung: ```backfill: Started JobId=...```
+* in den logs erkennbar an der Meldung: <code>backfill: Started JobId=...</code>
 * Parameter können die Laufzeit stark beeinflussen, hier die wichtigen:
-** ```bf_window```: 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 und schlechtere Responsiveness
+** <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 und schlechtere Responsiveness
-** ```bf_resolution```: 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_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
-** ```bf_busy_nodes```: weise 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_busy_nodes</code>: weise Jobs den Knoten zu, die bereits belegt sind, um Fragmentierung zu verringern bzw. freie Knoten für die Jobs freizuhalten, die ganze Knoten brauchen
-** ```bf_continue```: 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_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
-** ```bf_interval```: 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_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
-** ```bf_max_job_user```:  Nutzerlimit um zu vermeiden, dass ein Nutzer das Scheduling einer Iteration dominiert, default: keiner, Köln=30 Jobs
+** <code>bf_max_job_user</code>:  Nutzerlimit um zu vermeiden, dass ein Nutzer das Scheduling einer Iteration dominiert, default: keiner, Köln=30 Jobs
-** ```max_rpc_cnt```: wichtig für Responsiveness. Bei ```max_rpc_cnt``` aktiven Serverthreads legt der Backfiller eine Pause ein um anderen RPC Anfragen eine Change zu geben
+** <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 Change zu geben

Difference between revisions of "Admin Guide Scheduling Algorithms"