Next: Kommandos
Up: LSF - das neue
Previous: LSF - das neue
Bei klassischen Batchsystemen wie dem CXbatch (und ähnlichen, auf
NQS basierenden Systemen) werden Jobs je nach Anforderungen, vor
allem CPU-Zeit und Hauptspeicherbedarf, in Klassen eingeteilt und
jeder Jobklasse eine Queue zugeordnet. Dieses Verfahren funktioniert
gut, wenn die Verteilung der Jobs auf die Klassen im wesentlichen
gleich bleibt. In einer Umgebung mit sich ständig änderndem Jobmix wie
an einem Hochschul-Rechenzentrum treten aber sofort Probleme auf:
- Teilt man die Ressourcen eines Rechners komplett auf Queues auf,
kann die Maschine halb leer stehen, obwohl Jobs gerechnet werden könnten.
Treten etwa von einer Jobklasse weniger Jobs auf als geplant, werden die
der entsprechenden Queue zugeordneten Ressourcen nicht
ausgenutzt. Gleichzeitig warten aber u.U. Jobs in anderen Queues,
die eigentlich gerechnet werden könnten.
- Vergibt man aber mehr als die vorhandenen Ressourcen und hofft auf
eine vernünftige Verteilung, kann es leicht passieren, dass der
Rechner zu stark belastet wird, was zu verringerter Performance oder
sogar zu Abstürzen führen kann.
LSF geht daher einen anderen Weg: Im einfachsten Fall gibt es nur
eine einzige Queue, die alle Ressourcen einer Maschine
verwaltet. Ein Job spezifiziert seinen Bedarf und das Batchsystem
startet ihn, sobald die Anforderungen erfüllt werden können. Dabei
können sehr verschiedene Ressourcen angegeben werden, z.B.:
- CPU-Zeit
- Hauptspeicher
- Plattenplatz (etwa in /usertemp)
- Anzahl der CPUs
- Anzahl von Lizenzen einer bestimmten Software
- anderer Job ist fertig (Kettenjobs)
Können mehrere Jobs gestartet werden, gilt dabei natürlich
grundsätzlich das übliche Warteschlangen-Prinzip: Wer zuerst kommt,
rechnet zuerst. Dies kann bedeuten, dass ein einzelner Benutzer, der
eine große Zahl von Jobs absetzt, den Rechner auf längere Zeit mit
Beschlag belegt. Um auch dieses Problem zu lösen, gibt es bei LSF
eine zusätzliche Prioritäten-Steuerung. So kann man etwa dafür
sorgen, dass Jobs von Benutzern oder Arbeitsgruppen bevorzugt
werden, die in letzter Zeit weniger CPU-Zeit verbraucht haben oder
von denen gerade weniger Jobs laufen.
Ein weiteres Problem ist das Zusammenspiel von parallelen und
nicht-parallelen Jobs. Fordert etwa ein großer Paralleljob 8 CPUs
an, während gerade nur vier CPUs frei sind, wird er zunächst warten
müssen. Kleinere Jobs können aber gestartet werden, so dass
möglicherweise nie 8 CPUs gleichzeitig frei sind und der große Job
``verhungert''. Damit das nicht passiert, reserviert LSF die freien
CPUs und alle weiteren frei werdenden, bis der große Job gestartet
werden kann. Ein solches Vorgehen verschlechtert allerdings die
Auslastung, weil ja dadurch CPUs unbenutzt bleiben.
Dagegen verwendet LSF das folgende, als ``Backfilling'' bezeichnete
Verfahren: Da die Laufzeiten der Jobs beim Start angegeben werden
bzw. durch die maximale Laufzeit in der Queue begrenzt sind, kann
man abschätzen, wie lange es dauert, bis der große Job an der Reihe
ist. Die frei werdenden CPUs werden dann mit kleinen Jobs
beschäftigt, die rechtzeitig fertig sind, so dass sie den großen Job
nicht aufhalten. Auf diese Weise wird ein vernünftiger Kompromiss
zwischen dem Wunsch nach hoher Auslastung und den Anforderungen
großer Jobs erzielt.
Next: Kommandos
Up: LSF - das neue
Previous: LSF - das neue
cb
1999-12-02