Mit SLURM können Jobs mehr CPUs verwenden, als zum Starten angefordert werden

786
remek

Das Problem, dem ich mit SLURM gegenüberstehe, kann wie folgt zusammengefasst werden. Stellen Sie sich ein Bash-Skript vor test.sh, das 8 CPUs anfordert, aber tatsächlich einen Job mit 10 CPUs startet:

#!/bin/sh #SBATCH --ntasks=8 stress -c 10

Wenn ich auf einem Server mit 32 CPUs dieses Skript fünfmal mit 5 starte sbatch test.sh, laufen sofort 4 davon an, und das letzte erscheint als ausstehend, wie der squeueBefehl zeigt:

JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 5 main test.sh jack PD 0:00 1 (Resources) 1 main test.sh jack R 0:08 1 server 2 main test.sh jack R 0:08 1 server 3 main test.sh jack R 0:05 1 server 4 main test.sh jack R 0:05 1 server

Das Problem ist, dass diese 4 Jobs tatsächlich 40 CPUs verwenden und das System überlasten. Ich würde im Gegenteil davon ausgehen, dass SLURM entweder die Jobs nicht startet, die tatsächlich mehr Ressourcen als vom Benutzer angefordert beanspruchen, oder sie in die Warteschleife stellen, bis genügend Ressourcen vorhanden sind, um sie zu starten.

Einige nützliche Details zu meiner slurm.confDatei:

# SCHEDULING  #DefMemPerCPU=0  FastSchedule=1  #MaxMemPerCPU=0  SchedulerType=sched/backfill  SchedulerPort=7321  SelectType=select/cons_res  SelectTypeParameters=CR_CPU # COMPUTE NODES  NodeName=server CPUs=32 RealMemory=10000 State=UNKNOWN  # PARTITIONS  PartitionName=main Nodes=server Default=YES Shared=YES MaxTime=INFINITE State=UP

Ich fange gerade mit SLURM an und bin verblüfft über dieses Verhalten. Wie kann ich sicherstellen, dass die Benutzer meines Servers keine Jobs starten, die zu viele CPUs verwenden? Ich habe das Handbuch gelesen und viel Zeit damit verbracht, in Foren nach Informationen zu suchen. Leider fand ich nichts hilfreiches.

Vielen Dank im Voraus für Ihre Hilfe!

1

2 Antworten auf die Frage

1
Carles Fenoy

Slurm kann nicht wissen, wie viele Prozesse / Threads ein Skript erstellt. Es kann sich nur auf die angeforderten Ressourcen verlassen, und daher werden damit auch Jobs eingeplant.

Der beste Ansatz wird hier sein, eines der Affinitäts-Plugins in Slurm zu verwenden, um zu verhindern, dass Jobs mehr Ressourcen als benötigt beanspruchen. Diese Plugins binden einen Job an die angeforderte CPU. ( Affinitätsdokumentation )

Offensichtlich können Sie nicht steuern, wie viele Prozesse / Threads ein Benutzer in seinem Skript startet. Wenn Sie jedoch die Anzahl der Kerne, die ein Job verwenden kann, einschränken, verringern Sie die Auswirkungen, die ein unkontrollierter Benutzer auf andere Benutzerjobs haben kann.

Dies verhindert nicht, dass Ihr System als überlastet erscheint, die "schlechten" Benutzer wirken sich jedoch nur auf sie aus.

0
Tom

Nach unserer Diskussion bei SO habe ich versucht, das --exclusiveArgument dazu zu verwenden. Meine Architektur unterscheidet sich von Ihrer (Ihre zur Verfügung stehen 7 Prozessoren), aber ich habe Folgendes getan:

#!/bin/sh #SBATCH --ntasks=2  srun -n 2 --exclusive stress -c 1

und dann rennen

sbatch test.sh ; sbatch test.sh ; sbatch test.sh ; sbatch test.sh

gibt mir 6 stressProzesse:

15050 tom 20 0 7308 212 108 R 100.0 0.0 1:47.46 stress  15054 tom 20 0 7308 208 108 R 100.0 0.0 1:47.47 stress  15063 tom 20 0 7308 208 108 R 100.0 0.0 1:47.47 stress  15064 tom 20 0 7308 212 108 R 100.0 0.0 1:47.47 stress  15080 tom 20 0 7308 208 108 R 100.0 0.0 1:47.46 stress  15076 tom 20 0 7308 212 108 R 99.7 0.0 1:47.45 stress

der letzte wartet in der Warteschlange:

 JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 2368 Tom test.sh tom PD 0:00 1 (Resources) 2365 Tom test.sh tom R 5:03 1 Tom 2366 Tom test.sh tom R 5:03 1 Tom 2367 Tom test.sh tom R 5:03 1 Tom

In diesem Fall srun -n 2bewirkt die Verwendung, dass derselbe Prozess zweimal gestartet wird. Das gleiche passiert, wenn ich es benutze

#!/bin/sh #SBATCH --ntasks=2 srun -n 1 --exclusive stress -c 1 & srun -n 1 --exclusive stress -c 1 & srun -n 1 --exclusive stress -c 1 & wait

Das heißt, SLURM weiß, dass dieses Batch-Skript zwei Aufgaben hat, sodass zwei gleichzeitig ausgeführt werden können. der dritte muss "abwarten".

Auf der anderen Seite

#!/bin/sh #SBATCH --ntasks=1 srun -n 1 --exclusive stress -c 2

gibt mir das Verhalten, das Sie in Ihrer Frage beschreiben.

Ich bin mir nicht sicher, ob dies 100% antwortet, aber vielleicht hilft es ein bisschen.

Verwandte Probleme