Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

Inhalt

PBSPro bietet zur besseren Platzierung der Jobs einige Attribute um auf das Verhalten Einfluss zu nehmen. Jedoch versuchen wir die Anzahl dieser Optionen möglichst gering zu halten, da man sonst schnell durcheinander kommt oder fehlerhafte Anforderungen stellt.

...

Die UV2000 besteht aus jeweils 256 CPU-Cores und 8 TB Ram. Diese sind für das Batch-System aufgeteilt in 32 vNodes mit jeweils 8 CPU-Cores und dem dazugehörigen Memory von ca. 256GB Ram, welche direkt am Memory-Controller des CPUs liegen. Dadurch ist es dem Batch-System möglich einen Job per CGroup direkt an gewisse Speicherbänke und CPU-Cores zu binden, sodass keine Kommunikation über den NUMA-Link notwendig ist. Dieser NUMA-Link wird verwendet wenn mehr Ram oder Cores als in einer vNode vorhanden benötigt wird.

Unterscheidung der Architekturen

Der Scheduler ist so konfiguriert, dass zunächst versucht wird einen Job auf einem der kleinen MPI- Knoten laufen zu lassen und nur dann auf die UV2000 auszuweichen, wenn ansonsten kein Platz ist (auf Grund von Resourcenauslastung Ressourcenauslastung oder Anforderungen).

Auf Grund der Unterschiedlichen Architekten (Bsp.: Ivybridge vs. Sandybirdge-Prozessoren) kann es vorkommen, dass ein Job obwohl er klein ist besser auf der UV2000 läuft oder umgekehrt.

...

PBSPro ermöglicht es zu bestimmen, ob die einzelnen Chunks auf dem selben demselben Host laufen dürfen oder müssen oder ob ein Knoten exklusiv benötigt wird. Dazu gibt es das Attribut place welches folgende Werte besitzt:

...

Beispiel 1 würde den Job auf die UV2000 legen und dort drei vNodes beanspruchen, da die UV2000 pro vNode nur 8 Cores hat. Diese vNodes wären jedoch direkt nebeneinander, sodass es zu möglichst wenig Geschwindigkeitseinbusen Geschwindigkeitseinbußen käme.

Codeblock
languagebash
titleBeispiel 2
#PBS -l select=2:ncpus=12:mem=10GB
#PBS -l place=scatter

Beispiel 2 würde auf zwei verschiedenen Nodes auf dem Cluster gestartet werden, obwohl die zwei Chunks auch auf einen einzelnen MPI-Knoten passen würden. Dabei ist zu beachten, dass der Job auch auf einer vNode der UV2000 und einem MPI-Knoten mit unterschiedlicher CPU-Architektur und Taktrate starten kann. Dies muss sowohl bei der Kompilierung als auch bei der Laufzeit (Sync-Barrieres zwischen den Prozessen) berücksichtigt werden. Es empfiehlt sich also in diesem Fall auch das Attribut arch zu verwenden.


Konkreten GPU-Typ anfordern

Das Batchsystem erlaubt es einen speziellen GPU-Typ anzufordern. Dazu muss im Select-Statement der Wert accelerator_model gesetzt werden.

Folgende Werte werden derzeit unterstützt:

WertGPU-TypJahrAnzahl
gtx1080tiNvidia GTX 1080 TI2017120
rtx8000Nvidia Quadro RTX 800020204
rtx6000Nvidia Quadro RTX 6000202040
a100Nvidia A100202032


Codeblock
languagebash
titleBeispiel 2: GTX 1080Ti anfordern
#PBS -l select=1:ncpus=2:ngpus=1:accelerator_model=gtx1080ti


Codeblock
languagebash
titleBeispiel 3
#PBS -l select=1:ncpus=2:ngpus=4

In Beispiel 3 werden 4 GPUs auf einem Server angefordert