ZIVcluster: Häufig gestellte Fragen
Die folgende Sammlung häufig gestellter Fragen zum Thema ZIVcluster ist vermutlich weder wirklich erschöpfend noch repräsentativ. Die Problembereiche, mit denen man im Cluster-Alltag zu tun hat, sind so vielfältig, dass schon Fragen, die nur zweimal gestellt werden, das Kriterium der Häufigkeit erfüllen. Manche Fragen sind verallgemeinert worden, andere wiederum sind gewollt sehr spezifisch formuliert. Natürlich beginnt die Liste mit
1. Fragen zum Benutzeraccount
F: Könnten Sie für die Arbeitsgruppe x einen neuen Account für den Benutzer y anlegen mit folgenden Zugangsdaten (fremder Name und Kennung folgen)?
A: Zunächst einmal ist Voraussetzung, dass der Benutzer schon eine vom ZIV vergebene zentrale Kennung besitzt. Ist dies der Fall, sollte der Benutzer in jedem Fall selbst für seine Anmeldung über das IT-Portal sorgen (unter "Software und Systeme). Eine manuelle Einrichtung durch den Administrator sollte vermieden werden; der Grund hierfür ergibt sich aus der folgenden Frage:
F: Ehrlich gesagt wusste ich gar nicht, dass ich überhaupt als Nutzer am ZIVcluster angemeldet bin. Daher meine Bitte: Würden Sie mich bitte als Nutzer vom ZIVcluster löschen?
A: Selbstverständlich sollten Benutzer, die den Cluster nicht mehr nutzen wollen, eine kurze Mitteilung an den Administrator schicken. Der Plattenplatz ist knapp und wird von anderen Benutzern dringend benötigt. Ebenso sollte regelmäßiges Aufräumen durch den Benutzer eine Selbstverständlichkeit sein. Ein automatisiertes Löschen veralteter Dateien in Benutzer-Homeverzeichnissen findet nämlich nicht statt.
F: Ich habe mein Standard-ZIV-Passwort geändert, reicht das?
A: Nein, Sie müssen schon die entsprechende Schaltfläche unter "Mein ZIV" betätigen, damit das zentrale Standardpasswort auf den ZIVcluster übertragen wird. Zu Ihrer eigenen Sicherheit ist die Benutzerverwaltung auf dem ZIVcluster von der zentralen Benutzerverwaltung abgekoppelt, so dass Sie dort ein separates Passwort setzen können. Zur Passwortänderung auf dem Zivcluster muss auf der Kopfstation head0102 das Kommando "passwd" verwendet werden. Aus Sicherheitsgründen ist es sinnvoll, auf dem Cluster ein anderes als das zentrale Passwort zu verwenden und ebenso regelmäßig zu ändern. Wenn Sie es einmal vergessen haben, können Sie das zentrale Standardpasswort erneut von "Mein ZIV" aus übertragen.
F: Ich habe mein lokales Passwort auf dem ZIVcluster vergessen. Was nun?
A: Sie können über das IT-Portal das Passwort auf das zentrale Standardpasswort durch Anklicken der entsprechenden Schaltfläche (unter Software und Systeme) zurücksetzen. Natürlich sollten Sie weiterhin davon Gebrauch machen, danach mit "passwd" auf head0102 ein separates Passwort für den ZIVcluster zu setzen.
Für Nutzer des Rechnerverbundes NRW gilt weiterhin, dass wir zunächst einmal das zentrale Anfangspasswort der NRW-Kennung auf dem Cluster einsetzen. Das entsprechende Schreiben haben Sie hoffentlich aufbewahrt ...
2. Fragen zu Nutzungsmöglichkeiten und zur Installation
F: Auf dem Zivcluster müssen wir Standardprogramme mit sehr anspruchsvollen Problemgrößen rechnen. Leider haben wir aber Probleme mit dem Arbeitsspeicher auf dem ZIVcluster. Anscheinend stehen uns als Default nur 900 MB zur Verfügung. Wir benötigen aber ca. 2 GB. Wir würden uns daher freuen, wenn Sie dieses Limit für unseren Account höher setzen könnten.
A: Die Knoten auf dem Cluster haben nur 1 GB Hauptspeicher. Etwa 150 MB davon werden vom System selbst benötigt und stehen für Benutzer-Prozesse ebenfalls nicht zur Verfügung. Exzessives Swapping hingegen führt das Konzept des Hochleistungsrechnens ad absurdum und führt außerdem zu instabilen Systemen bis hin zu Abstürzen. Daher ist der Adressraum für jeden Benutzerprozess auf 850 MB limitiert. Die Speicherbänke der Rechenknoten sind voll belegt, daher kommt auch eine Aufrüstung des Hauptspeichers mit diesem Cluster nicht in Frage, zumal die Speichermodule praktisch nirgendwo sonst wiederverwertet werden können. Bei manchen parallelen Programmen kann man durch Verwendung von mehr Rechenknoten den Speicherbedarf pro Knoten reduzieren. Leider funktioniert das nicht immer.
F: Kann es angehen, dass Benutzer xy so viel Rechenzeit auf unserem Cluster verbraucht, und das als Gast von einer anderen Uni? Haben wir eigentlich zuviel Rechenzeit oder was?
A: Da der Cluster etwa zu 20 Prozent aus Mitteln des NRW-Verbunds bezahlt worden ist, steht Benutzern aus anderen Unis des Landes NRW auch ein entsprechender Anteil an der Rechenzeit zu. Dieser Anteil ist bisher jedenfalls noch nicht voll ausgeschöpft worden, auch wenn er vielleicht in einer Momentaufnahme einmal überschritten worden ist.
F: Ich möchte ein eigenes Programmpaket auf dem Cluster installieren, darf ich das?
A: Dafür ist der Cluster ja gedacht. Wenn es sich allerdings um ein Standard-Programmpaket handelt, welches für einen größeren Benutzerkreis von Interesse ist, sollte eine zentrale Installation einer Installation im eigenen Homeverzeichnis vorgezogen werden. Und insbesondere wenn andere Methoden zur Kommunikation als die vorinstallierten (MPICH-GM, MPICH-P4) verwendet werden sollen, muss der Benutzer dafür Sorge tragen, dass nur die vom Batch-System zugewiesenen Rechenknoten verwendet werden und Jobs anderer Benutzer dadurch nicht gestört werden. Auch für die Einhaltung von Lizenzbedingungen ist dann natürlich der Benutzer selbst verantwortlich.
F: Zur grafischen Auswertung meiner Daten benötige ich das Programm xy. Kann man dieses Programm auch auf dem ZIVcluster installieren?
A: Sofern sich der Aufwand dafür vertreten lässt. RPM-Pakete, die für die Linux-Distribution vorliegen, stellen kein Problem dar. Programme, die einen Kompiliermarathon nach sich ziehen, weil sie eine Unmenge von Bibliotheken benötigen, die der Distributor nicht anbietet oder nur in inkompatiblen Versionen, sind eher schlechte Kandidaten. Anders sieht es aus, wenn das Programmpaket für die Berechnungen selbst erforderlich ist (Beispiele: APBS, NAMD, ScaLAPACK, ...). Die grafische Aufbereitung von Daten sollte ohnehin eher auf normalen Arbeitsplatzrechnern erfolgen, da hierfür meist kein paralleler Rechenbedarf besteht.
F: Kann man nicht mal schnell eine neue Compiler-Version installieren?
A: Nicht, wenn die neue Compiler-Version eine neue Betriebssystemversion erfordert. Bei den Systemvoraussetzungen achte man unter anderem auf die Kompatibilität zur bestehenden GNU C Library (glibc). Ein Update des Betriebssystems erfordert ein Neukompilieren nahezu aller zuvor angepassten Bibliotheken und Programmpakete (MPICH, Gaussian, ...) und dementsprechend langfristige Planung. (Nachtrag: Mit dem derzeit aktuellen Intel-Compiler konnte z.B. keine funktionierende MPICH-Version gebaut werden; sämtliche Konsistenzprüfungen der Ergebnisse des Linpack-Benchmarks schlagen damit fehl).
F: Kann ich meine Programme und Skripte auf einem Windows-System schreiben und dann einfach auf den Cluster kopieren? Mir gefällt mein Editor hier einfach besser.
A: Beim Kopieren mittels Secure Copy von einem Windows-System bleiben die MS-DOS-Steuerzeichen für Zeilenumbrüche erhalten. Diese bringen das Batch-System durcheinander, in der Form, dass ausführbare Programme innerhalb eines normal aussehenden PBS-Skriptes nicht gefunden werden. Dem Programmnamen hängt dann nämlich noch ein unsichtbares Steuerzeichen an. Falls man dies als Fehlerursache für angeblich nicht auffindbare Programme vermutet, sind die Befehle "file" und "recode" hilfreich. Angenommen, das Job-Skript job.pbs wurde mit einem Windows-Editor erstellt und auf den Cluster kopiert, dann lässt sich der Fehler vermeiden durch:
[lewelin@head0102 lewelin]$ file job.pbs
job.pbs: ASCII English text, with CRLF line terminators
[lewelin@head0102 lewelin]$ recode ibmpc..latin1 job.pbs
[lewelin@head0102 lewelin]$ file job.pbs
job.pbs: ASCII English text
Anschließend kann das Skript problemlos mit qsub job.pbs abgeschickt werden.
3. Fragen zum Batch-System
F: Kann ich ohne Benutzung des Batch-Systems auf dem Cluster rechnen?
A: Sie können schon, dürfen aber nicht. Am Batch-System vorbeigeschleuste Prozesse auf den Rechenknoten werden ohne Vorwarnung abgebrochen. Das gilt auch im Fall unabsichtlicher Fehlbedienungen wie z. B. fehlerhafter PBS-Skripte.
F: Warum sind die Wartezeiten im Batch-System so lang?
A: Angesichts der Tatsache, dass ein Job auf dem Cluster eine Woche lang auf bis zu 80 Knoten rechnen darf, sind die Wartezeiten eigentlich zumutbar. Von den bisher abgearbeiteten Jobs haben 73% weniger als 10 Minuten, 86% weniger als 4 Stunden und 94% weniger als einen Tag auf die Ausführung warten müssen. Ganze 1,2% aller Jobs mussten länger als eine Woche warten, bei diesen beläuft sich aber auch die durchschnittliche Anzahl der angeforderten Knoten auf 18,6. In den meisten Fällen macht es einfach keinen Sinn, mehr als 16 Knoten zu verwenden. Für Tests von Algorithmen und Benchmarks, die gelegentlich sehr viele Knoten für kurze Zeit erfordern, ist eigens die Queue "dedicatedq" erdacht worden. Diese hat eine garantierte Wartezeit von einer Woche; wer länger wartet, ist meistens selbst schuld.
F: Welche Kriterien verwendet PBS bei der Auswahl von Jobs?
A: Die Antwort auf diese Frage fällt etwas umfangreicher aus: Zunächst einmal gilt natürlich im Prinzip, dass ältere Jobs jüngeren vorgezogen werden. Dabei gibt es allerdings Ausnahmen von dieser Regel (strict_fifo: false all), insbesondere:
Kein Benutzer kann mehr als vier "running jobs" haben. Dabei ist es gleich, wie viele Jobs dieses Benutzers in der Queue stehen, mehr als vier Jobs werden nicht gleichzeitig ausgeführt (max_user_run = 4).
Das Batchsystem kann Jobs aus einer Queue mit höherer Priorität solchen mit geringerer Priorität vorziehen. Je länger die Laufzeit einer Queue, desto geringer ist die Priorität von Jobs in dieser Queue. Ältere Jobs, die viele Knoten anfordern, können dann leicht schon mal mehrere Tage bis zwei Wochen in der Queue stehen, bevor sie ausgeführt werden. Die Prioritäten der Queues sind auf der Homepage des Clusters aufgelistet. Die Philosophie dahinter ist natürlich, dass man für einen Langzeit-Job auch längere Wartezeiten in Kauf nehmen muss als für einen Kurzzeit-Job. Das ist ähnlich wie beim Arbeitsamt: Kurzzeit-Jobs sind eben schneller vermittelbar. Nach einer gewissen Zeit (160 Stunden) werden "verhungernde" Jobs als solche gekennzeichnet und mit einer höheren Priorität behandelt (help_starving_jobs: true all).
Um "Langzeitarbeitslose" wird sich also besonders gekümmert. Nach etwa zwei Wochen werden gar alle anderen Jobs an der Ausführung gehindert, bis endlich genügend Rechenknoten für den am längsten wartenden Job frei sind. Es gilt das Fair-Share-Prinzip: Nach einem internen Punktesystem werden jedem Benutzer Punkte für verbrauchte Rechenzeit angeschrieben, die mit einer Halbwertszeit von 24 Stunden wieder abgebaut werden. Wer also in jüngster Vergangenheit viel gerechnet hat, steht punktemäßig schlechter da als die Konkurrenz und muss jemandem Platz machen, der weniger Punkte auf dem Konto hat. Dadurch wird verhindert, dass jemand den Cluster für sich blockieren kann, indem er 20 Jobs hintereinander in die Queue schickt. Also kann es durchaus passieren, dass jemand, der wochenlang nicht gerechnet hat, einem Benutzer vorgezogen wird, der eigentlich schon viel früher 5 Jobs in die Queue gestellt hat.
F: Woran erkenne ich, warum mein Job nicht losläuft?
A: Die Ausgabe von qstat -f Job-Id enthält eine entsprechende Kommentarzeile (comment = ...), die eine von mehreren möglichen Ursachen aufzeigt. Beispielsweise: Not enough of the right type of nodes are available kann hier erscheinen, wenn zwar insgesamt genügend Knoten frei wären, aber nicht in der Queue, die man gewählt hat. Auch genügt schon eine einzige falsche Ressourcenanforderung (etwa 2 GB Hauptspeicher), damit ein Job überhaupt nicht gestartet wird. Sofern im Browser JavaScript aktiviert ist, kann man diesen Kommentar auch über die Webseite http://zivcluster.uni-muenster.de/cgi-bin/qview in kleinen PopUp-Fenstern anzeigen lassen. Es wird aber immer nur eine Ursache angezeigt; so kann es vorkommen, dass ein Job nicht läuft, weil erstens das Limit von vier gleichzeitigen Jobs überschritten ist und außerdem nicht genügend Knoten frei wären. Manchmal haben alle Jobs bis auf einen den gleichen Kommentar: Draining the system to allow starving job to run. In diesem Fall wird Platz geschaffen für einen Job, der schon wesentlich länger als eine Woche in der Queue wartet.
F: Gibt es eine Strategie, schnell einen parallelen Job ausführen zu können?
A: Ja, solange man sich am aktuellen Zustand des Clusters orientiert. Auf dieser Webseite wird für jede Queue einzeln die aktuelle Anzahl verfügbarer Knoten angezeigt. Solange man nicht gerade in letzter Zeit viel gerechnet und eine entsprechend schlechte Punktwertung nach dem Fair-Share-Prinzip auf dem Konto hat, kann man normalerweise die freien Knoten sofort für sich nutzen. Ansonsten kann man aber auch durch andere Maßnahmen die Wartezeit minimieren:
1. Man wähle eine maßvolle und gängige Anzahl von Knoten (z. B. 4 oder 8 statt 5 oder 24).
2. Man orientiere sich an den Restlaufzeiten der anderen Jobs: Wenn man sieht, dass ein 16-Knoten-Job in der bigq bereits 155 Stunden gelaufen ist, kann man mit Sicherheit davon ausgehen, dass diese 16 Knoten in genau fünf Stunden frei werden. Also wäre es eher ungeschickt, in dieser Situation 20 Knoten anzufordern.
F: Auf der Queue-Webseite wird mein Job als running angezeigt und hat angeblich auch schon stundenlang gerechnet. Weiter unten sehe ich aber, dass mein Job auf den Knoten gar nichts macht. Woran liegt das?
A: Die häufigste Ursache ist ein falsches "Machinefile" beim Aufruf von MPI-Programmen. In diesem Fall rechnet der Job zwar, aber nicht auf den vom PBS zugewiesenen Knoten, sondern irgendwo sonst im Cluster. Das ist besonders ärgerlich, wenn dadurch Jobs anderer Benutzer beeinträchtigt werden oder gar Knoten wegen Hauptspeichermangels abstürzen. Eine weitere mögliche Ursache könnte ein fehlerhaftes GPFS-Dateisystem sein. Meistens wird der Benutzer dann früher oder später der Fehlermeldung Stale NFS file handle begegnen. In diesem Fall wird der Administrator den PBS-Scheduler anhalten, alle hängenden Jobs, die noch nicht lange gerechnet haben, mit qrerun neu in die Queue stellen und das Dateisystem reparieren. Sobald der Scheduler wieder aktiviert wird, kann der Job ordnungsgemäß anlaufen.
F: Ich möchte auf keinen Fall, dass ein aufgrund eines Systemfehlers abgebrochener Job vom Administrator neu gestartet wird. Kann ich das irgendwie verhindern?
A: Ja, indem man beim Aufruf von qsub die Option "-r n" angibt. Damit kann der Benutzer den Job als not rerunable kennzeichnen. Das ist zum Beispiel dann sinnvoll, wenn der Job Eingabedateien bereits überschrieben hat und so ein erneuter Start andere Ergebnisse als erwartet produzieren würde.
F: Warum rechnen alle Jobs mit nice, ich möchte doch so schnell wie möglich rechnen?
A: Der Nice-Level aller Benutzer-Prozesse ist systemseitig erzwungen und sollte normalerweise vom Benutzer auch nicht verändert werden können. Die Erfahrung zeigt, dass der Cluster mit dieser Voreinstellung stabiler läuft, da insbesondere Systemprozesse, die das GPFS-Dateisystem verwalten, auf exaktes Timing angewiesen sind. Andererseits macht ihrem Job ja auch niemand außer dem System selbst CPU-Zyklen streitig, so dass der Job kaum schneller läuft, wenn er sich nicht »nett« verhält.
F: Mein Job wurde mit einem Fehler abgebrochen, und nun habe ich eine Mail bekommen mit folgendem Inhalt:
PBS Job Id: 13229.head0101.cluster.uni-ms
Job Name: abcde6
Post job file processing error; job 13229.head0101.cluster.uni-ms on host node0236/0
Unable to copy file 13229.head0.OU to head0102:/gpfs/u/rutherf/parallel3/output.dat
>>> error from copy
head0102.cluster.uni-ms: No route to host
>>> end error output
Output retained on that host in: /var/spool/PBS/undelivered/13229.head0.OU
Leider kann ich diese Datei nicht finden, wo kann die abgeblieben sein?
A: Die Datei wird auf dem Headnode nicht zu finden sein. Die Angabe on host node0236/0 sagt eigentlich schon alles. Sie dürfen sich auf diesem Knoten per ssh einloggen und die Datei in Ihr eigenes Heimatverzeichnis verschieben. Man kann aber auch einen Tag lang warten und auf dem Headnode einmal das Kommando pbsundel aufrufen. Dieses sammelt nämlich solche Dateileichen ein und legt sie im Dateibereich des Benutzers unter $HOME/.pbs-undelivered/ ab. Das sollte man aber möglichst dann tun, wenn alle Knoten sowie das GPFS ordnungsgemäß funktionieren. Ein Hinweis an alle Benutzer: Zurzeit gibt es übrigens noch einige solcher Leichen im Keller!
F: Mein Job läuft nicht, stattdessen bekomme ich eine E-Mail mit der Fehlermeldung (verkürzt):
>>> error from copy
No value for $TERM and no -T specified
>>> end error output
Was geht hier schief?
A: Vermutlich haben Sie an den Login-Skripten herumgebastelt (also .login, .profile oder .bashrc). Das PBS verträgt unter anderem keine zusätzlichen Textausgaben beim Login auf einen Knoten, wie zum Beispiel die Anzeige des Plattenplatzes oder ähnlicher Meldungen. In einem Fall führte sogar die Umdefinition des Login-Prompts (normalerweise [user@hostname directory]$) in der Datei .alias zu einem solchen Fehler. Bei Änderungen an den Login- und Shell-Konfigurationen behalten Sie bitte eine Kopie der Originalversion, damit Sie selbst überprüfen können, ob diese Änderungen für das Fehlverhalten des Batch-Systems verantwortlich sind.
Stand: 02.02.2009