Difference between revisions of "Admin Guide Scheduling Algorithms"
Admin Guide Scheduling Algorithms
Jump to navigation
Jump to search
(Author Marcus Wagner) |
|||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Category:HPC-Admin]] | + | [[Category:HPC-Admin|Scheduling Algorithms]]<nowiki /> |
| − | [[Category:HPC.NRW-Best-Practices]] | + | [[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. | Unfortunately, this article is currently only available in German but will be translated soon. | ||
| Line 14: | 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/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/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] | ** [https://slurm.schedmd.com/sched_config.html Slurm scheduling Configuration Guide] | ||
| Line 28: | 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_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 | * 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. | ||
Latest revision as of 11:54, 13 February 2023
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.
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 (siehesched_min_interval), checkt dabei höchstensdefault_queue_depthpending Jobs - interval-triggered: unabhängig von den events wird die gesamte queue (alle pending Jobs) in bestimmten Intervallen (
sched_interval) gescannt - 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 Zuweisungsched_min_interval: erzwingt Wartezeit zwischen Aufrufen. Wie beideferwird damit Responsiveness erhöht. Default: 2us, in Köln: 2secsched_interval: alle pending Jobs werden gescannt, der default von 60sec ist sinnvolldefault_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 niedrigem 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 sowie die Laufzeit und entspr. schlechtere Responsivenessbf_resolution: Planungsgenauigkeit, bei grossen Planungshorizont muss sie entspr. verringert werden (default: 1 Min, Köln: 30 Min), je ungenauer bzw. grösser, desto bessere Responsivenessbf_busy_nodes: weist Jobs den Knoten zu, die bereits belegt sind, um Fragmentierung zu verringern bzw. freie Knoten für die Jobs freizuhalten, die ganze Knoten brauchenbf_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 Parameterbf_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 Minbf_max_job_user: Joblimit per Nutzer um zu vermeiden, dass ein Nutzer das Scheduling einer Iteration dominiert, default: keiner, Köln=30 Jobsmax_rpc_cnt: wichtig für Responsiveness. Beimax_rpc_cntaktiven 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.