Queuing System auf SGI Cray Origin2000

Queuing System auf SGI Cray Origin2000
======================================

Seit Anfang Maerz steht auf der SGI Cray Origin2000 (fp98.zserv) ein neuartiges
Queuing System zur Verfuegung.

Mit der Betriebsystemversion IRIX-6.5 steht ein zusaetzlicher Scheduler
(Miser Scheduler) zur Verfuegung, der es erlaubt Resourcen (CPUs und
Hauptspeicher) fuer eine bestimmte Zeit zur reservieren. In diesem Zeitraum
stehen die reservierten Resourcen den entsprechenden Prozessen exklusiv
zur Verfuegung; die Anzahl der context switches kann dadurch extrem reduziert
werden.

Die Laufzeit serieller Jobs kann durch den Einsatz von Miser um 5-10%
verbessert werden, bei parallelen Jobs konnten Verbesserungen bis zu 30%
beobachtet werden (bei einer Systemauslastung von etwa 70%).
Generell wird durch den Einsatz von Miser ein wesentlich besseres Verhalten
im Hochlastbereich gewaehrleistet; bei voll ausgelastetem System konnte
eine Steigerung der Durchsatzleistung von ueber 15% erreicht werden.

Der Miser Scheduler verhaelt sich dem Benutzer gegenueber wie ein
rudimentaeres Queuing System; daher wurde der Miser Scheduler mit
Craysoft NQE kombiniert. Craysoft NQE entspricht in der Funktionalitaet
Sterling NQS, das auf den SGI Power Challenge Systemen eingesetzt wird.

 

 

Das folgende Beispiel soll die Funktionsweise des Systems verdeutlichen;
Mit den Kommando

qsub cpu=4 memory=200m time=24h my_job

wird ein Request, der 4 CPUs, 200 MB Hauptspeicher und insgesamt 24
Stunden Rechenzeit benoetigt, an das System gestellt.
Aufgrund der angegebenen Resourcen wird der Request in eine bestimmte
NQE-Queue eingereiht. Sobald der Miser Scheduler die Reservierung der
angeforderten Resourcen durchfuehren kann, wird der Request von der
NQE-Queue an die Miser Queue weitergegeben.
Mit Beginn des Reservierungszeitraumes wird der Request dann tatsaechlich
gestartet.

Waehrend der Programausfuehrung ist ein Ueberschreiten der bei der
Reservierung angegebenen Limits nicht moeglich (die konkreten Werte
beziehen sich auf obiges Beispiel):


  • 4 CPUs reserviert, Request startet aber 10 Threads:
    die 10 Threads muessen sich 4 CPUs teilen, auch wenn andere CPUs
    frei waeren.

  • 200 MB Hauptspeicher reserviert, Request benoetigt aber mehr:
    In diesem Fall wird der gesamt Request terminiert.
    Alle zu einem Request gehoerenden Prozesse duerfen in Summe nicht
    mehr (physikalisch vorhandenen) Hauptspeicher belegen als reserviert
    wurde.

  • 24 Stunden Zeitlimit wird ueberschritten:
    In diesem Fall wird der gesamt Request terminiert.
    Im obigen Beispiel werden 24 Stunden Rechenzeit reserviert, die
    aber auf 4 CPUs aufgeteilt werden; d.h. der Request wird nach
    24/4=8 Stunden vom Miser Scheduler terminiert.

 

 

Ausfuehrlichere Informationen sind online am System verfuegbar.