Es wird fairshare scheduling eingesetzt. Ob ein Job A vor einem Job B gestartet wird, hängt im Wesentlichen von zwei Faktoren ab:

• wann der Job abgeschickt wurde
• wie viele Shares der Nutzer zur Verfügung hat

In der Regel wird ein Job, der vor einem anderen an das Batch-System abgeschickt wurde, schneller gestartet werden als der andere. Allerdings verbraucht ein Nutzer ensprechend der in Anspruch genommen CPU-Zeit , GPU-Zeit oder Hautptspeicher sogenannte Shares, wenn ein Job von ihm läuft. Je mehr Shares ein Nutzer noch zur Verfügung hat, desto stärker werden seine Jobs bevorzugt. Mit der Zeit werden einem neue Shares gut geschrieben. Damit soll der Zugang zu den Rechenressourcen gerecht gestaltet werden.

Dieser Mechanismus spielt nur dann eine Rolle, wenn Jobs um die gleichen Ressourcen konkurrieren. Sind genügend Ressourcen frei, kann man auch dann neue Jobs starten, wenn einem keine Shares mehr zur Verfügung stehen.

Die Priorität eines Jobs wird hauptsächlich durch folgende Faktoren, in der Reihenfolge ihrer Wichtigkeit, bestimmt.

• User-Shares - Die Anzahl der Shares im Sinne des Fairshare-Scheduling, die eine Nutzerin hat, bildet den Hauptfaktor. Je mehr Shares eine Nutzerin hat, desto höher wird die Priorität ihres Jobs sein. Der Verbrauch von CPU-Zeit, GPU-Zeit und Hautptspeicher (RAM) verringert die Anzahl von Shares und setzt damit die Priorität wartender Jobs ab.

• Job-Alter - Wie lange ein Job schon in der Warteschlange wartet, ist ein weiterer wichtiger Faktor. Allerdings ist der Wert begrenzt und erreicht nach ein gewisser Zeit ein Maximum.

• Job-Größe - Die Priorität von Jobs, die mehr Knoten beantragen, wird etwas erhöht.

Die Faktoren, die die Priorität der aktuell wartenden Jobs bestimmen, können mit folgendem Kommando angeschaut werden. Dabei werden die Ergebnisse werden nach der Gesamtpriorität sortiert.

sprio -Sy

Die Speichermenge, die von einem Job benötigt wird, sollte in dem Kontrolskript angegeben werden. Man muss versuchen, den Wert möglichst genau zu spezifizieren.

Wenn der Wert zu hoch ist, dann

• wird der Job eventuell länger als notwendig warten müssen, bis genug Speicher frei wird.

• werden andere Jobs, sobald der Job startet, eventuell werden warten müssen, weil ConsumableMemory aufgebraucht wurde, obwohl Speicher tatsächlich zur Verfügung steht. Im Diagramm unten kann der gezeigte Job trotz verfügbarer Cores in ausreichender Zahl nicht starten, weil das Batch-System nicht genug Speicher auf dem Knoten reservieren kann.

Wenn der Wert zu klein ist, dann

• wird der Job beim Überschreiten der angegeben ConsumableMemory beendet.

Backfill ist ein Mechanismus, der dafür sorgt, dass ein Job mit niedriger Priorität vor einem mit höherer Priorität gestartet werden kann, ohne dass der Start des Jobs mit höherer Priorität verzögert wird.

In der Abbildung unten sei Job A ein Job, der gerade angelaufen ist. Job B, der die von Job A belegten Knoten sowie weitere Knoten benötigt, muss warten, bis Job A zu Ende ist. Falls Job C eine kürzere maximale Laufzeit hat als Job A, dann kann Job C vor Job B starten, auch wenn Job B eine höhere Priorität hat und ohne, dass der Start von Job B verzögert wird. So können "Lücken" im Belegungsplan gefüllt werden und damit kann ein besserer Durchsatz im Cluster erreicht werden.

Man beachte, dass ein Job nur dann von Backfilling profitieren kann, wenn die notwendige Laufzeit für den Job wesentlich kleiner ist, als das Default-Maximum und wenn diese Zeit angegeben wird. Als Beispiel für Slurm legt folgende Zeile

#SBATCH --time=2-12:00:00 

eine Obergrenze von 2 Tagen und 12 Stunden fest. Je kürzer die angegebene Zeit, desto stärker kann der Job von Backfilling profitieren. Sollte der Job die Zeitgrenze allerdings erreichen, wird er vom Batch-System beendet. Vgl. man sbatch für weitere Details.