Hi,
ich beobachte in den letzten zwei Wochen eine verstärkte Nutzung der Slurm Nodes, jedoch scheinbar von verschiedenen Personen jeweils begrenzt auf einen oder wenige Nodes.
Ich möchte ich ermutigen, Eure Jobs so zu spoolen, dass Ihr nicht Nodes (nodelist) sondern Bedingungen (constraint) beschreibt. Das könnte nach meiner Einschätzung den Effekt haben, dass Ihr mehr Nodes nutzen könnt und so insgesamt im Falle vieler Jobs schneller fertig werdet, da oft andere User gar keine laufenden Jobs haben.
Habt keine Sorge, dass Ihr andere Jobs damit verdrängt. Der Scheduler sollte eine faire Verteilung der Ressourcen gewährleisten.
Denkt unter anderem an den mem-Parameter, um auch auch nebenläufige single-threaded Jobs auf gemeinsamen Nodes zu ermöglichen, da der Scheduler anderenfalls annimmt, der Job braucht den gesamten Speicher des jeweiligen Node. Zahlreiche Cores bleiben dann ungenutzt.
Lest bitte auch die Wiki-Seite und helft gerne mit, sie zu verbessern:
https://wiki.ibr.cs.tu-bs.de/en/slurm
Viele Grüße -frank
können wir einen Constraint haben, der alle Nodes anspricht, die eine (physikalisch in dem Server befindliche) schnelle SSD unter opt/tmpssd haben? Können noch mehr Server eine solche SSD bekommen?
On 23.08.23 15:04, Frank Steinberg wrote:
Hi,
ich beobachte in den letzten zwei Wochen eine verstärkte Nutzung der Slurm Nodes, jedoch scheinbar von verschiedenen Personen jeweils begrenzt auf einen oder wenige Nodes.
Ich möchte ich ermutigen, Eure Jobs so zu spoolen, dass Ihr nicht Nodes (nodelist) sondern Bedingungen (constraint) beschreibt. Das könnte nach meiner Einschätzung den Effekt haben, dass Ihr mehr Nodes nutzen könnt und so insgesamt im Falle vieler Jobs schneller fertig werdet, da oft andere User gar keine laufenden Jobs haben.
Habt keine Sorge, dass Ihr andere Jobs damit verdrängt. Der Scheduler sollte eine faire Verteilung der Ressourcen gewährleisten.
Denkt unter anderem an den mem-Parameter, um auch auch nebenläufige single-threaded Jobs auf gemeinsamen Nodes zu ermöglichen, da der Scheduler anderenfalls annimmt, der Job braucht den gesamten Speicher des jeweiligen Node. Zahlreiche Cores bleiben dann ungenutzt.
Lest bitte auch die Wiki-Seite und helft gerne mit, sie zu verbessern:
https://wiki.ibr.cs.tu-bs.de/en/slurm
Viele Grüße -frank
slurm-users mailing list --slurm-users@ibr.cs.tu-bs.de To unsubscribe send an email toslurm-users-leave@ibr.cs.tu-bs.de
Am 23.08.2023 um 15:06 schrieb pullwitt pullwitt@ibr.cs.tu-bs.de:
können wir einen Constraint haben, der alle Nodes anspricht, die eine (physikalisch in dem Server befindliche) schnelle SSD unter opt/tmpssd haben?
Okay. Das muss allerdings noch warten, bis wieder mal alle Nodes idle sind. Erst dann ist solch eine Konfigurationsänderung möglich. Ich werde die Option dann „tmpssd“ nennen.
Können noch mehr Server eine solche SSD bekommen?
Derzeit haben folgende Hosts ein lokales /opt/tmpssd (mind. 440GB): i3, i4, i5, crunch1, crunch2, crunch3. Ggf. könnte ich crunch4-7 auch noch welche geben.
participants (2)
-
Frank Steinberg
-
pullwitt