In dieser Anleitung zeigen wir Ihnen einige häufige Fehlerquellen, die bei der Stapelverarbeitung von Jobs auf der Rescale-Plattform auftreten. Wir zeigen Ihnen, wie Sie einige dieser Fehler diagnostizieren und wie Sie sie vermeiden und beheben können.
Seite „Auftragsstatus“
Überprüfen Sie die Ausgabe des Jobs Status Seite
Untersuchen Sie den Auftragsverlauf im Gantt-Diagramm
Übergibt der Befehl die ValidierungsprüfungenBei der Validierung geht es darum, sicherzustellen, dass ein Produkt, System oder … Mehr Schritt (Validierung der Eingabe) mit einem grünen Häkchen? Liegen Fehlermeldungen vor in der Jobprotokolle Abschnitt?
Liegen Fehlermeldungen vor in der Jobprotokolle Abschnitt?
Ergebnisseite
process_output.log
Der erste Schritt, den wir immer empfehlen würden für jeder Job, erfolgreich oder nicht, ist die Überprüfung der process_output.log Datei. Diese Datei protokolliert die Standardausgabe der von Ihnen ausgeführten Softwareanalysemethode. Außerdem werden alle möglichen Fehlermeldungen protokolliert.
Für die process_output.log Datei gehen Sie zum Job Ergebnisse Seite
Abfrage der Datei in der Suchleiste
Gewöhnlich log or process ist ein ausreichender Suchbegriff
Klicken Sie sich einfach durch um die process_output.log Datei über das Bildschirmsymbol im Aktion Überblick
Wenn die Datei zu groß ist, müssen Sie sie möglicherweise zuerst herunterladen, bevor Sie sie in einem Texteditor anzeigen können
Überprüfen Sie diese Protokolldatei sorgfältig und suchen Sie nach Warn- oder Fehlermeldungen
Meistens, der Fehler kann hier identifiziert werden
Beendigungscodes
Ein wichtiges Feld, nach dem Sie suchen sollten, ist der „Exit-Code“ am Ende des process_output.log Datei. Wenn eine Analysemethode reibungslos läuft und ohne Fehlermeldungen beendet wird, sollte sie Folgendes erzeugen:
Beenden mit Code 0
Während ein Job mit code 0bedeutet dies lediglich, dass der Prozess fehlerfrei lief. Dies bedeutet natürlich keine Garantie dass der Job wie gewünscht ausgeführt wurde. Wenn das Programm einen expliziten Systemfehler feststellt (z. B. zu wenig Speicher, Coreeine einzelne Verarbeitungseinheit innerhalb eines Mehrkernprozessors oder ... Mehr Dump, nicht genügend Speicherplatz usw.), erzeugt der Prozess einen Exitcode ungleich Null. Häufige Exitcodes, die Ihnen begegnen können:
Beendigungscode
Bedeutung
1
Catchall für allgemeine Fehler
2
Missbrauch von Shell-Built-Ins
126
Der aufgerufene Befehl kann nicht ausgeführt werden
127
Befehl nicht gefunden
128
Ungültiges Argument zum Beenden
128+n
Schwerwiegendes Fehlersignal „n“
130
Skript mit Strg-C beendet
137
Unbestimmter Beendigungsmodus, einschließlich expliziter Beendigung des Prozesses oder unzureichendem Arbeitsspeicher
255 *
Beendigungsstatus außerhalb des Bereichs
Diese Fehlercodes sind natürlich nicht besonders aufschlussreich, bieten jedoch einen Ausgangspunkt für die Fehlerbehebung.
Grundlegende Schritte zum Debuggen
Obwohl es eine Vielzahl von Fehlermechanismen gibt, sind im Folgenden einige der häufigsten Probleme sowie Schritte zu ihrer Diagnose und Vermeidung aufgeführt.
Fehlende Eingabedateien
Stellen Sie sicher, dass alle erforderlichen Dateien entweder einzeln oder in einem komprimierten (ZIP, Tarball usw.) Eingabedateistapel in den Auftrag aufgenommen wurden.
Falsche Dateipfade
Stellen Sie sicher, dass das komprimierte Eingabedateipaket in die richtigen Verzeichnispfade erweitert wird
Verwenden Sie relative Dateipfade in Skripten, Eingabedateien und anderen Jobdefinitionen
Rescale führt die Software aus Befehl(s) angegeben auf der Softwareeinstellungen Seite im selben Arbeitsverzeichnis, in dem die komprimierten Dateien entpackt werden
Die Rescale-Plattform geht davon aus, dass die vorbereiteten Eingabedateien auf der obersten Verzeichnisebene gepackt sind
zip/tar/etc die Eingabedateien auf der Verzeichnisebene, in der der Befehl ausgeführt wird
Oder, wenn ein Fall-Unterverzeichnis verwendet wird (dh run01_configB), stellen Sie sicher, dass Sie dem Befehl der Analysesoftware die richtige Verzeichnisänderung voranstellen, beispielsweise: cd run01_configB && run_analysis
Beachten Sie, dass dies nicht der bevorzugte Arbeitsablauf auf der Rescale-Plattform ist
Jobs mit mehreren Knoten, die Zugriff auf ein gemeinsames Dateisystem erfordern
Für die meisten Analysemethoden, bei denen der Hauptprozess die Datei-E/A und die Kommunikation mit dem Arbeitsprozess übernimmt, platziert Rescale standardmäßig benutzerdefinierte Eingabedateien in ~/workEinige Methoden starten jedoch Arbeitsprozesse auf Knoten, die auch Zugriff auf ein gemeinsam genutztes Dateisystem benötigen.
Auf der Rescale-Plattform ~/work/shared Das Verzeichnis ist per NFS auf allen Compute-Knoten in Ihrem Job gemountet
Rescale hat die meisten dieser Analysemethoden erkannt und startet standardmäßig Jobs in der ~/work/shared Verzeichnis
Gelegentlich benötigen die auf den Knoten ausgeführten Arbeitsprozesse jedoch aufgrund einer Laufzeitanpassung oder -option Zugriff auf Eingabedateien, laden Laufzeitbibliotheken oder schreiben Ausgabedateien.
Das Befehl auf die Softwareeinstellungen Seite sollte vorangestellt werden mit schlauer bewegen und ändere die Richtung Befehle:
mv * von Locals geführtes
cd von Locals geführtes
<Analyse ausführen>
Fehler beim Lesen der Eingabedateien
Stellen Sie sicher, dass die Eingabedateien wie von Ihrer Analysesoftware erwartet erstellt werden
Stellen Sie sicher, dass die richtige Software Version ist auf der Dropdown-Seite „Softwareeinstellungen“ ausgewählt
Stellen Sie sicher, dass die Texteingabedateien das richtige Format haben
Batch-Rechnerknoten sind in der Regel Linux-Rechner. Je nach verwendetem Texteditor werden Zeilen-/Dateiendezeichen manchmal unterschiedlich kodiert.
Oftmals erzeugen Windows-Texteditoren Dateien mit der ^M Zeilenumbruchzeichen, das Linux nicht verwendet
Um dies mithilfe eines Texteditors wie VI/VIM zu ersetzen, können Sie diese Zeichen durch den folgenden Befehl ersetzen: :%s/^M$//
Hinweis: ^M wird eingegeben als ctrl-V und ctrl-M
Untersuchen Sie andere Protokolldateien Ihrer Analysemethode
Während die Rescale-Plattform Standardausgabenachrichten ausgibt an process_output.log, einige Analysemethoden drucken kritische Informationen in andere Protokolldateien
Die Ausgabedateien haben in der Regel die Dateierweiterungen „log“, „out“, „live“ oder „dat“, können aber je nach Analysemethode variieren. Bitte beachten Sie die Dokumentation des Softwareanbieters.
Diese Protokolldateien sind in der Regel auch ASCII-Textdateien, sodass Sie sie über das kleine Bildschirmsymbol in der rechten Spalte neben dem Dateinamen anzeigen können.
Wie bei der process_output.log Wenn die Datei zu groß ist, laden Sie sie auf Ihren lokalen Computer herunter. ArbeitsplatzEine Workstation ist ein leistungsstarkes Computersystem, das für professionelle Zwecke entwickelt wurde. Mehr und sie mit einem Texteditor anzeigen
Fehlende Bibliotheksdateien
Stellen Sie sicher, dass der Prozess über den richtigen Zugriff und die richtigen Pfaddefinitionen für alle im Job verwendeten benutzerdefinierten Bibliotheksdateien verfügt.
Der Rescale-Support muss möglicherweise zusätzliche Bibliotheken für Ihre Anwendung installieren.
Überprüfen Sie, ob Ihre SimulationSimulation ist Experimentieren, Testen von Szenarien und Erstellen von … Mehr Der Prozess verfügt während der Laufzeit über ausreichend physischen Speicher und Speicherplatz
Einige Codes ändern je nach Analyse die Größe ihres Speicherbedarfs während der Laufzeit, sodass beim Start möglicherweise nicht genügend Speicher vorhanden ist.
Einige Codes erzeugen außerdem eine große Menge an Scratch-Datendateien, die den Speicherbedarf über den der endgültigen Ausgabedateien hinaus aufblähen können.
Siehe die „Clusterstatus“ auf der Unterseite des Jobs Status Seite zur Anzeige von freiem Arbeitsspeicher und Speicherplatz
Reduzieren Sie die Größe Ihres Netzes/Ihrer Simulation, um zu sehen, ob der Job erfolgreich ausgeführt werden kann
Ausführung auf mehreren Kernen und/oder Knoten
Wählen Sie spezielle Kerntypen mit mehr physischem Speicher oder Speicherplatz
Ordnungsgemäßer Lizenzzugriff
Stellen Sie sicher, dass Ihre Lizenzeinstellungen auf der Softwareeinstellungen Seite richtig definiert sind. Im Allgemeinen liegen diese im Format Port@Hostname vor.
Stellen Sie sicher, dass Sie die Funktionen in Ihrer Lizenzdatei auschecken, wie aus der Datei process_output.log ersichtlich.
Überprüfen Sie, ob mit dem Befehl, den Sie ausführen möchten, die richtigen Optionen zum Auschecken der Funktionen verwendet werden.
Wenn Sie die für Ihre Lizenz verantwortliche Person sind ServerEin Server ist ein Computerprogramm, das Dienste für andere bereitstellt. Mehr:
Überprüfen Sie, ob Ihre Lizenz abgelaufen ist
Überprüfen Sie, ob Ihr Lizenzserver aktiv ist und über Netzwerkzugriff verfügt
Bevor Sie mit einem Produktionslauf beginnen, richten Sie einen kleinen Testfall ein, der Ihren Workflow übt
Überprüfen Sie, ob Ihre Vor- und Nachbearbeitungsschritte richtig in Ihre Analyseoptionen > Befehl
Führen Sie einen Testjob interaktiv aus
Ersetzen Sie die vorhandene Befehl und sleep 3600
ssh in den Computer KnotenIn der herkömmlichen Datenverarbeitung ist ein Knoten ein Objekt in einem Netzwerk. ... Mehr sobald es beginnt
Wechseln Sie in das entsprechende Verzeichnis für Ihre Analysemethode (~/work or ~/work/shared)
Versuchen Sie, den Job interaktiv zu starten
Notieren Sie alle Befehle, die zu einem erfolgreichen Ergebnis führen
Ändern Sie Ihre Befehl(s) dementsprechend
Das Befehl Eingabefenster akzeptiert Zeilenumbrüche, ; or && Markierungen zum Trennen von Befehlen
Hinweis: Befehle getrennt durch && wird nur ausgeführt, wenn der vorherige mit einem abgeschlossen wird code 0, während diejenigen, die folgen ; wird immer nach dem vorherigen ausgeführt
Wenn diese allgemeinen Debugging-Schritte Ihre Probleme immer noch nicht lösen, kontaktieren Sie uns bitte und teilen Sie uns Ihren Job mit Unterstützung für Neuskalierung.
Wenn die Datei zu groß ist, müssen Sie sie möglicherweise zuerst herunterladen, bevor Sie sie in einem Texteditor anzeigen können 
