Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Slurmspeicherbasierte Terminplanung
AWS ParallelCluster Unterstützt ab Version 3.2.0 Slurm speicherbasiertes Scheduling mit dem Cluster-Konfigurationsparameter/. SlurmSettingsEnableMemoryBasedScheduling
Anmerkung
Für die AWS ParallelCluster Versionen 3.2.0 bis 3.6. x EnableMemoryBasedScheduling kann nicht aktiviert werden, wenn Sie mehrere Instanztypen in Instances konfigurieren.
Warnung
Wenn Sie mehrere Instance-Typen in einer Slurm Queue-Computing-Ressource mit EnableMemoryBasedScheduling aktivierter Option angeben, ist der RealMemory Wert die Mindestmenge an Arbeitsspeicher, die allen Instance-Typen zur Verfügung gestellt wird. Dies kann zu erheblichen Mengen an ungenutztem Speicher führen, wenn Sie Instance-Typen mit sehr unterschiedlichen Speicherkapazitäten angeben.
Mit EnableMemoryBasedScheduling: true verfolgt der Slurm Scheduler die Menge an Speicher, die jeder Job auf jedem Knoten benötigt. Anschließend verwendet der Slurm Scheduler diese Informationen, um mehrere Jobs auf demselben Rechenknoten zu planen. Die Gesamtmenge an Speicher, die Jobs auf einem Knoten benötigen, darf nicht größer sein als der verfügbare Knotenspeicher. Der Scheduler verhindert, dass ein Job mehr Speicher beansprucht, als beim Absenden des Jobs angefordert wurde.
Mit EnableMemoryBasedScheduling: false können Jobs auf einem gemeinsam genutzten Knoten um Arbeitsspeicher konkurrieren und zu Auftragsausfällen und out-of-memory Ereignissen führen.
Warnung
Slurmverwendet für seine Bezeichnungen eine Zweierpotenz, z. B. MB oder GB. Lesen Sie diese Beschriftungen jeweils als MiB und GiB.
SlurmKonfiguration und speicherbasiertes Scheduling
Mit Slurm legt EnableMemoryBasedScheduling: true die folgenden Slurm Konfigurationsparameter fest:
-
SelectTypeParameters=CR_CPU_Memoryim slurm.conf. Diese Option konfiguriert den Knotenspeicher als verbrauchbare Ressource in. Slurm -
ConstrainRAMSpace=yesin der. Slurm cgroup.confMit dieser Option ist der Speicherzugriff eines Jobs auf die Speichermenge beschränkt, die der Job bei der Übermittlung angefordert hat.
Anmerkung
Verschiedene andere Slurm Konfigurationsparameter können sich auf das Verhalten des Slurm Schedulers und des Ressourcenmanagers auswirken, wenn diese beiden Optionen festgelegt sind. Weitere Informationen finden Sie in der Slurm-Dokumentation.
SlurmScheduler und speicherbasiertes Scheduling
EnableMemoryBasedScheduling: false(Standard)
EnableMemoryBasedSchedulingist standardmäßig auf „Falsch“ gesetzt. Wenn der Wert falsch Slurm ist, nimmt der Speicher nicht als Ressource in seinen Planungsalgorithmus auf und verfolgt nicht den Speicher, den Jobs verwenden. Benutzer können die --mem MEM_PER_NODE Option angeben, um die Mindestmenge an Speicher pro Knoten festzulegen, die ein Job benötigt. Dadurch wird der Scheduler gezwungen, MEM_PER_NODE bei der Planung des Jobs Knoten mit einem RealMemory Wert von mindestens auszuwählen.
Nehmen wir zum Beispiel an, dass ein Benutzer zwei Jobs mit einreicht. --mem=5GB Wenn angeforderte Ressourcen wie CPUs oder GPUs verfügbar sind, können die Jobs gleichzeitig auf einem Knoten mit 8 GiB Arbeitsspeicher ausgeführt werden. Die beiden Jobs sind nicht auf Rechenknoten mit weniger als 5 GiB geplantRealMemory.
Warnung
Wenn die speicherbasierte Planung deaktiviert ist, wird Slurm nicht nachverfolgt, wie viel Speicher die Jobs verwenden. Jobs, die auf demselben Knoten ausgeführt werden, konkurrieren möglicherweise um Speicherressourcen und führen dazu, dass der andere Job fehlschlägt.
Wenn die speicherbasierte Planung deaktiviert ist, empfehlen wir Benutzern, die Optionen --mem-per-cpu--mem-per-gpu
EnableMemoryBasedScheduling: true
Wenn auf true gesetzt EnableMemoryBasedScheduling ist, wird die Speichernutzung jedes Jobs Slurm verfolgt und verhindert, dass Jobs mehr Speicher verwenden, als mit den --mem Übermittlungsoptionen angefordert wurde.
Im vorherigen Beispiel sendet ein Benutzer zwei Jobs mit--mem=5GB. Die Jobs können nicht gleichzeitig auf einem Knoten mit 8 GiB Arbeitsspeicher ausgeführt werden. Das liegt daran, dass die insgesamt benötigte Speichermenge größer ist als der Speicher, der auf dem Knoten verfügbar ist.
Wenn die speicherbasierte Planung aktiviert ist, --mem-per-cpu und --mem-per-gpu verhalten Sie sich konsistent mit dem, was in der Slurm Dokumentation beschrieben ist. Zum Beispiel wird ein Job mit eingereicht. --ntasks-per-node=2 -c 1 --mem-per-cpu=2GB In diesem Fall Slurm weist dem Job insgesamt 4 GiB für jeden Knoten zu.
Warnung
Wenn die speicherbasierte Planung aktiviert ist, empfehlen wir Benutzern, bei der Einreichung eines Jobs eine --mem Spezifikation anzugeben. Wenn in der Slurm Standardkonfiguration keine Speicheroption enthalten ist ( AWS ParallelCluster, oder--mem-per-gpu) --mem--mem-per-cpu, wird dem Auftrag der gesamte Speicher der zugewiesenen Knoten zugewiesen, auch wenn er nur einen Teil der anderen Ressourcen wie Slurm CPUs oder GPUs anfordert. Dadurch wird die gemeinsame Nutzung von Knoten effektiv verhindert, bis der Job abgeschlossen ist, da kein Speicher für andere Jobs verfügbar ist. Das liegt daran, dass der Arbeitsspeicher pro Knoten für den Job auf den Zeitpunkt Slurm gesetzt wird, zu DefMemPerNode
Wenn mehrere Typen von Rechenressourcen mit unterschiedlichen Speichermengen in derselben Warteschlange verfügbar sind, werden einem ohne Speicheroptionen eingereichten Job möglicherweise unterschiedliche Speichermengen auf verschiedenen Knoten zugewiesen. Das hängt davon ab, welche Knoten der Scheduler für den Job zur Verfügung stellt. Benutzer können auf Cluster DefMemPerNode - oder Partitionsebene in den Slurm Konfigurationsdateien einen benutzerdefinierten Wert für Optionen wie oder definieren DefMemPerCPU
Slurm RealMemory und AWS ParallelCluster SchedulableMemory
Wird in der AWS ParallelCluster mitgelieferten Slurm Konfiguration als die Menge an Speicher pro Slurm Knoten interpretiert RealMemoryRealMemory, der in Amazon EC2 EC2-Instanztypen aufgeführt und von den Amazon EC2
Wenn die speicherbasierte Planung deaktiviert ist, filtert der Slurm Scheduler Knoten, wenn Benutzer einen RealMemory Job mit den angegebenen Werten einreichen. --mem
Wenn die speicherbasierte Planung aktiviert ist, interpretiert RealMemory der Slurm Scheduler die maximale Speichermenge, die für Jobs verfügbar ist, die auf dem Rechenknoten ausgeführt werden.
Die Standardeinstellung ist möglicherweise nicht für alle Instance-Typen optimal:
-
Diese Einstellung ist möglicherweise höher als die Speichermenge, auf die Knoten tatsächlich zugreifen können. Dies kann passieren, wenn es sich bei den Rechenknoten um kleine Instance-Typen handelt.
-
Diese Einstellung ist möglicherweise niedriger als die Speichermenge, auf die Knoten tatsächlich zugreifen können. Dies kann passieren, wenn es sich bei Rechenknoten um große Instance-Typen handelt, und kann zu einer erheblichen Menge an ungenutztem Speicher führen.
Sie können SlurmQueues/ComputeResources/verwenden SchedulableMemory, um den Wert von RealMemory configured by AWS ParallelCluster für Compute-Knoten zu optimieren. Um den Standardwert zu überschreiben, definieren Sie einen benutzerdefinierten Wert SchedulableMemory speziell für Ihre Clusterkonfiguration.
Um den tatsächlich verfügbaren Speicher eines Rechenknotens zu überprüfen, führen Sie den /opt/slurm/sbin/slurmd -C Befehl auf dem Knoten aus. Dieser Befehl gibt die Hardwarekonfiguration des Knotens einschließlich des RealMemoryslurmd
-C
Stellen Sie sicher, dass die Betriebssystemprozesse des Compute-Knotens über ausreichend Arbeitsspeicher verfügen. Beschränken Sie dazu den für Jobs verfügbaren Speicher, indem Sie den SchedulableMemory Wert auf einen niedrigeren Wert als den vom slurmd -C Befehl zurückgegebenen RealMemory Wert setzen.
