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.
# Slurm speicherbasierte Terminplanung
Ab Version 3.2.0 unterstützt AWS ParallelCluster Slurm speicherbasiertes Scheduling mit dem [`SlurmSettings`[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)](Scheduling-v3.md#Scheduling-v3-SlurmSettings)Cluster-Konfigurationsparameter/.
**Anmerkung**
`EnableMemoryBasedScheduling`[Kann ab AWS ParallelCluster Version 3.7.0 aktiviert werden, wenn Sie mehrere Instanztypen in Instances konfigurieren.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Für die AWS ParallelCluster Versionen 3.2.0 bis 3.6. *x*, `EnableMemoryBasedScheduling` kann nicht aktiviert werden, wenn Sie mehrere Instanztypen in [Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) konfigurieren.
**Warnung**
Wenn Sie mehrere Instanztypen in einem angeben Slurm Wenn die Rechenressource in der Warteschlange `EnableMemoryBasedScheduling` aktiviert ist, entspricht der `RealMemory` Wert der Mindestmenge an Arbeitsspeicher, die allen Instance-Typen zur Verfügung steht. Dies kann zu erheblichen Mengen an ungenutztem Speicher führen, wenn Sie Instance-Typen mit sehr unterschiedlichen Speicherkapazitäten angeben.
Mit`EnableMemoryBasedScheduling: true`, dem Slurm Der Scheduler verfolgt die Menge an Speicher, die jeder Job auf jedem Knoten benötigt. Dann ist der Slurm Der Scheduler verwendet 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 Auftragsfehlern und `out-of-memory` Ereignissen führen.
**Warnung**
Slurm verwendet für seine Bezeichnungen eine Zweierpotenz, z. B. MB oder GB. Lesen Sie diese Labels als MiB bzw. GiB.
## Slurm Konfiguration und speicherbasierte Planung
Mit `EnableMemoryBasedScheduling: true` Slurm legt Folgendes fest Slurm Konfigurationsparameter:
+ [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory) im `slurm.conf`. Diese Option konfiguriert den Knotenspeicher als verbrauchbare Ressource in Slurm.
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)in der Slurm `cgroup.conf`. Mit dieser Option ist der Speicherzugriff eines Jobs auf die Speichermenge beschränkt, die der Job bei der Übermittlung angefordert hat.
**Anmerkung**
Mehrere andere Slurm Konfigurationsparameter können sich auf das Verhalten des auswirken Slurm Scheduler und Ressourcenmanager, wenn diese beiden Optionen festgelegt sind. Weitere Informationen finden Sie hier: [Slurm Dokumentation](https://slurm.schedmd.com/documentation.html).
## Slurm Scheduler und speicherbasierte Planung
**`EnableMemoryBasedScheduling: false`(Standard)**
`EnableMemoryBasedScheduling`ist standardmäßig auf „Falsch“ gesetzt. Wenn falsch, Slurm nimmt 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 verfügbar GPUs 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 geplant`RealMemory`.
**Warnung**
Wenn die speicherbasierte Planung deaktiviert ist, Slurm verfolgt nicht die Menge an 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 [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu)oder [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu)nicht anzugeben. Diese Optionen können zu einem Verhalten führen, das sich von dem unterscheidet, was in der [Slurm Dokumentation](https://slurm.schedmd.com/documentation.html).
**`EnableMemoryBasedScheduling: true`**
Wann `EnableMemoryBasedScheduling` ist auf true gesetzt, Slurm verfolgt die Speichernutzung der einzelnen Jobs 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 auf dem Knoten verfügbare Speicher.
Wenn die speicherbasierte Planung aktiviert ist, `--mem-per-cpu` `--mem-per-gpu` verhalten Sie sich konsistent mit den Anweisungen in Slurm -Dokumentation. 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. Mit der Standardeinstellung Slurm Konfiguration, die in enthalten ist AWS ParallelCluster, falls keine Speicheroption enthalten ist (`--mem`,`--mem-per-cpu`, oder`--mem-per-gpu`), Slurm weist dem Job den gesamten Speicher der zugewiesenen Knoten zu, auch wenn er nur einen Teil der anderen Ressourcen anfordert, z. B. CPUs oder GPUs. 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 passiert, weil Slurm legt den Speicher pro Knoten für den Job auf den Wert fest, [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)wenn zum Zeitpunkt der Auftragsübergabe keine Speicherspezifikationen angegeben wurden. Der Standardwert für diesen Parameter ist 0 und gibt unbegrenzten Zugriff auf den Speicher eines Knotens an.
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 einen benutzerdefinierten Wert für Optionen wie `DefMemPerNode` oder auf Cluster [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU)- oder Partitionsebene in der Slurm Konfigurationsdateien, um dieses Verhalten zu verhindern.
## Slurm RealMemory und AWS ParallelCluster SchedulableMemory
Mit dem Slurm Konfiguration, die mitgeliefert wird AWS ParallelCluster, Slurm wird als die Menge an Speicher pro Knoten interpretiert [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory), die für Jobs verfügbar ist. Ab Version 3.2.0 sind standardmäßig 95 Prozent des Speichers AWS ParallelCluster festgelegt`RealMemory`, der in [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types) aufgeführt und von der EC2 Amazon-API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)zurückgegeben wird.
Wenn die speicherbasierte Planung deaktiviert ist, Slurm Scheduler filtert Knoten`RealMemory`, wenn Benutzer einen Job mit den angegebenen Werten einreichen. `--mem`
Wenn die speicherbasierte Planung aktiviert ist, Slurm Der Scheduler interpretiert dies als `RealMemory` 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`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/verwenden [`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-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 [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)Werts zurück. Weitere Informationen finden Sie unter [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C).
Stellen Sie sicher, dass die Betriebssystemprozesse des Rechenknotens ü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.