Admin Guide Scheduling Algorithms - Revision history

Lech-nieroda-2eba@uni-koeln.de: /* Backfilling Scheduler */

2023-02-13T10:54:51Z

Backfilling Scheduler

Lech-nieroda-2eba@uni-koeln.de: /* Main Scheduler */

2023-02-13T10:47:50Z

Main Scheduler

Lech-nieroda-2eba@uni-koeln.de: /* Main- und Backfilling-Scheduler */

2021-05-29T21:33:48Z

Main- und Backfilling-Scheduler

Lech-nieroda-2eba@uni-koeln.de at 21:20, 29 May 2021

2021-05-29T21:20:55Z

Lech-nieroda-2eba@uni-koeln.de: Main- und Backfilling Scheduler hinzugefügt

2021-05-29T21:14:03Z

Main- und Backfilling Scheduler hinzugefügt

Mukund-pondkule-6a11@uni-paderborn.de at 18:17, 9 December 2020

2020-12-09T18:17:52Z

Robert-schade-e757@uni-paderborn.de at 15:46, 2 November 2020

2020-11-02T15:46:40Z

Robert-schade-e757@uni-paderborn.de at 15:09, 2 November 2020

2020-11-02T15:09:16Z

Robert-schade-e757@uni-paderborn.de: Author Marcus Wagner

2020-10-31T17:27:28Z

Author Marcus Wagner

New page

[[Category:HPC-Admin]]
[[Category:HPC.NRW-Best-Practices]]

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

@@ Line 62: / Line 62: @@
 ** <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 Change zu geben. Ein Erfahrungswert, muss niedrig genug sein damit der Server schnell reagieren kann und hoch genug um zeitnahes Scheduling zu ermöglichen.
+** <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.

@@ Line 45: / Line 45: @@
 * 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: 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: 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 ===

@@ Line 41: / Line 41: @@
 * 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: scannt die gesamte queue (alle pending Jobs) in bestimmten Intervallen (<code>sched_interval</code>)
+* 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: 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
 ** <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
@@ Line 52: / Line 52: @@
 * 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)
+* 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 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 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>: 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>: 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>:  Nutzerlimit um zu vermeiden, dass ein Nutzer das Scheduling einer Iteration dominiert, default: keiner, Köln=30 Jobs
+** <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 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. Ein Erfahrungswert, muss niedrig genug sein damit der Server schnell reagieren kann und hoch genug um zeitnahes Scheduling zu ermöglichen.

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

@@ Line 1: / Line 1: @@
-[[Category:HPC-Admin|Scheduling Algorithms]]
+[[Category:HPC-Admin|Scheduling Algorithms]]<nowiki />
-[[Category:HPC.NRW-Best-Practices|Scheduling Algorithms]]
+[[Category:HPC.NRW-Best-Practices|Scheduling Algorithms]]<nowiki />
-[[Category:Slurm]]
+[[Category:Slurm]]<nowiki />
 Unfortunately, this article is currently only available in German but will be translated soon.

@@ Line 16: / Line 16: @@
 * 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 eingesetzt, da der Scheduler hier versucht Tetris zu spielen, also Lücken aufzufüllen die z.B. “vor” großen Jobs entstehen.
+* 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]
@@ Line 30: / Line 30: @@
 * 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