Die Nutzung des Lichtenberg HPC ist nur über Projekte möglich, denen die genehmigte Anzahl Kernstunden zugewiesen wird und die somit festlegen, wieviel Rechenressourcen das Projekt auf dem HPC verbrauchen darf. Im Grunde definieren die dem Projekt zugewiesenen Kernstunden den „Anteil“ dieses Projekts an den Gesamtressourcen des HPC.
Alle im Verlauf des Projekts beanspruchten Kernstunden werden auf das Projekt gebucht (wie ausgegebenes Geld bei einem Bankkonto).
Mitgliedschaften in Projekten
Um ein Projekt für Ihre wissenschaftlichen Berechnungen (mit)nutzen zu können, müssen Sie Mitglied werden. Infos zur Projektmitgliedschaft
Benutzer vs. Projekt
Ein Benutzerzugang/-account (personalisiert) ist mindestens einem Projekt zugeordnet (wobei das erste zum Standardprojekt des Benutzers wird). Anders als der personengebundene Benutzeraccount kann und darf ein Projekt von mehreren Kollegen bzw. Studierenden genutzt werden, die gemeinsam an demselben wissenschaftlichen Problem arbeiten.
Geben Sie niemals Ihren Benutzeraccount (Passwort oder ssh-Keys) weiter! Gemeinsames Arbeiten ist nur im Rahmen von Projekten gestattet.
Ablauffristen
Da Projekte mehrere Nutzer/Mitglieder haben können, und andererseits ein bestimmter Nutzer Mitglied in mehreren Projekten sein kann, besteht zwischen den Gültigkeitsfristen von HLR-Nutzerzugängen und HLR-Projekten keinerlei Zusammenhang – beide laufen unabhängig voneinander (aus). Ebenso umfasst die Verlängerung des einen nicht die Verlängerung des jeweils anderen.
Jobs vs. Projekt
Das Abschicken von Batch-Jobs ohne (impliziten) Projektbezug ist nicht möglich. Gibt ein/e Benutzer/in den entsprechenden Parameter sbatch -A <Projekt> nicht an, wird der Job auf deren Standardprojekt gebucht.
Accounting-Regeln
Der Lichtenberg-Cluster läuft im Modus „user-exclusive“: ein Rechenknoten wird gleichzeitig immer nur Jobs desselben Nutzers ausführen.
Das bedeutet aber auch, dass bereits ein einziger (kleiner) Job den Knoten für andere Nutzer blockiert. Daher wird Ihrem Projekt auch für einen 4-Kern-Job der ganze Knoten (96 Kerne) angerechnet!
Fordert man für solch kleinere Rechenjobs aber glatte Teiler der Rechenkern-Anzahl unserer Knoten an (und nicht übermäßig viel Speicher), können sich mehrere Ihrer Jobs einen Rechenknoten ohne „Verschnitt“-Verluste von Ressourcen teilen:
Vermeiden Sie dafür unbedingt das Pragma
#SBATCH --exlusivedenn das würde jedem einzelnen (kleinen) Job einen separaten Rechenknoten zuweisen und obiges „Sharing“ unterbinden!
Ressourcenverbrauch
Jede/r Benutzer/in kann mit den Kommandos csum und csreport eine Übersicht über die von seinen Projekten bisher genutzten Ressourcen abrufen.
Monatliche Verbrauchsübersicht
An jedem Monatsende erhält jede/r Nutzer/in eine automatische EMail mit einer Verbrauchsübersicht aller Projekte, denen er/sie zugeordnet ist („Lichtenberg User Report“).
Auslastungsgrafik
Seit Oktober 2019 enthält die monatliche Mail zur Verbrauchsübersicht eine Grafik, die die Aktivitäten des jeweiligen Projekts grafisch darstellt. Sie ermöglicht den Nutzenden einen besseren Einblick in den Ressourcenverbrauch und die Effizienz ihrer Projekte.
Die Darstellung ist zweigeteilt – oben ein kombinierter Graph der verbrauchten Prozessorzeit und unten eine Effizienzdarstellung der einzelnen Jobs.
Teil A)
Der obere Graph zeigt die verbrauchten Kernstunden über die Laufzeit des Projekts einschließlich des vergangenen Monats.
Die graue Linie verdeutlicht alle bisher angesammelten Kernstunden, die auf dieses Projekt gebucht bzw. verbraucht wurden.
Darin enthalten sind sowohl
- Kernstunden, die über das Projekt genutzt wurden, als auch
- Kernstunden, die nur aufgrund des „exclusive“-Prinzips für Jobs dieses Projekts blockiert wurden.
Die gelbe Linie repräsentiert den Anteil an verbrauchten Kernstunden, den die Prozessorkerne tatsächlich mit den wissenschaftlichen Berechnungen verbracht haben (vergleichbar mit „user time“).
Beispiel:
Wenn ein Job auf 16 Prozessorkernen 10h lang mit einer tatsächlichen Prozessoreffizienz von 50% läuft, werden dem Projekt 160 Kernstunden (graue Linie) angerechnet, obwohl nur 80 Kernstunden (gelbe Linie) für die eigentliche Berechnung aufgewendet wurden.
Dabei ist nur die tatsächliche Laufzeit entscheidend: selbst wenn hierfür 12h Laufzeit im Jobscript angefordert wurden, geht nur die wirkliche Laufzeit von 10 Stunden in die Berechnung ein.
Die farbigen Balken zeigen den monatlichen Verbrauch des Projekts an (jeweils am bis dahin verbrauchten Wert aufsetzend). Ihre Farbe verdeutlicht die jeweils relative Nutzung, bezogen auf das monatliche Kontingent des Projekts.
Beispiel:
Wenn einem Projekt ein monatlicher Anteil von 17.000 Kernstunden zugewiesen wurde, in einem Monat aber 19.000 Kernstunden verbraucht wurden, ist der jeweilige Monatsbalken gelb (110% – 150%).
Der Balken des Folgemonats beginnt nun an der grauen Linie (bisher verbraucht) PLUS 17.000 Kernstunden (Kontingent des neuen Monats).
Falls das Projekt über den aktuellen Monat hinaus läuft, wird der Ressourcenverbrauch bis zum Laufzeitende aus den bisherigen Monaten extrapoliert (schwarze Linie).
Teil B)
Die untere Darstellung zeigt die Prozessoreffizienz der einzelnen Jobs des Projekts, also den Quotienten aus tatsächlich genutzten Kernstunden geteilt durch verbrauchte Kernstunden (und nicht etwa angeforderte Kernstunden).
Jeder Job wird durch einen halbtransparenten violetten Punkt repräsentiert. Mehrere Jobs mit derselben Effizienz überlagern einander und erscheinen als dunklere Punkte.
Die kleineren roten Punkte zeigen die durchschnittliche Prozessoreffizienz pro Tag an (sofern an diesem Tag Jobs für das Projekt liefen). Da sich die violetten Punkte nicht nach Job-Laufzeit und -Größe unterscheiden, helfen die roten Punkte beim Bewerten der Effizienz verschiedener Tage mit verschiedenen Job-Eigenschaften.
Zur Zeit erfasst diese Grafik nur reine Prozessor-Metriken und keine Kernstunden auf Beschleunigerkarten (z.B. GPUs).
Falls Sie den Plot für Ihr(e) Projekt(e) in einem auflösungsunabhängigen Vektorformat benötigen, können Sie uns gern kontaktieren (siehe unten).
HKHLR-Werkzeuge
Für die Ermittlung der Effizienz einzelner Jobs oder die Identifikation von Jobs mit bestimmten Effizienzprofilen bietet das HKHLR auch Hilfsmittel an.
Dazu muss das Modul JobAnalysisTools des HKHLR mittels
module load hkhlr JobAnalysisTools/0.1in einem Jobscript geladen werden.
Danach stehen drei Werkzeuge zur Verfügung:
mittels
HKHLR_RecentJobEfficiencyReport kann man für die jüngsten Jobs (Standard: 7 Tage) eine Liste der Effizienz abrufen.
Ruft man
HKHLR_JobReport $JOBIDauf, erhält man die CPU-Effizienz dieses einen Jobs.
Zuletzt gibt das Script
HKHLR_GetJobIDsOfInterval $lowerBound $upperBoundall die JOBIDs zurück, deren Effizienz zwischen $lowerBound und $upperBound lag.
Falls Sie weitere Hilfe bzw. Erklärungen benötigen oder Rückmeldungen haben, können Sie sich gern an das HKHLR wenden -- entweder über das Ticketsystem der TU Darmstadt oder per Mail an darmstadt@hpc-hessen.de.